SQL Server'da (2005 veya 2008) içinde bir nokta bulunan bir veritabanı adı kullanırsam, "MyApp.Sales" gibi bir şey, bu herhangi bir soruna yol açar mı?
SQL Server'da (2005 veya 2008) içinde bir nokta bulunan bir veritabanı adı kullanırsam, "MyApp.Sales" gibi bir şey, bu herhangi bir soruna yol açar mı?
Yanıtlar:
Sen can , ama olmaz. DB adını daima [MyApp.Sales] gibi köşeli ayraçlarla sarmanız gerekir.
Özetlemek gerekirse: akıl sağlığına değer veriyorsan, yapma.
Teknik olarak mümkün olsa bile bence çok kötü bir fikir .
Yıllar geçtikçe, pek çok insanın, dört bölümlü adlandırma kuralını oldukça açık görünse de, anlamada zorluk çektiğini öğrendim:
server_name.database_name.schema_name.object_nameBöyle bir şey görürlerse ne olacağını bir düşünün:
MAIN-SQL.[MyApp.Sales].hr.CompetitorsProductsveya:
[MAIN-SQL\EXPRESS].[MyApp.Sales].sch_HR.[Products From.Our-Competitors]Her şeyi basit tutmak önemlidir.
Bu soruya başkasıyla karşılaşırsanız ...
Kullanıcıların kafası karışabileceği için değil, aynı zamanda bazı araçların kafası karışabileceği için bunun sadece kötü bir fikir olmadığını unutmayın.
Microsoft'un bile bu konuda sorunları var. Veritabanınızı Microsoft Query (ODBC aracılığıyla) kullanarak bir excel sayfasına bağlamaya çalışırsanız, bağlanmak istediğiniz veritabanını seçmenize olanak tanıyan bir yapılandırma sihirbazı elde edersiniz. Ancak, nokta içeren bir veritabanı seçmek, sunucunun bulunamadığını bildiren bir hataya neden olacaktır. Sihirbaz, değerlerin kaçmaya ihtiyacı olup olmadığını kontrol etmiyor ve tanımlayıcıları kör bir şekilde birleştiriyor gibi görünüyor.
Elbette çalışma ortamları var, ancak baştan bunu yapmamakla kendinize biraz sıkıntı kazandırıyorsunuz.
Veritabanı isimlerinde, yayın isimlerinde, kullanıcı isimlerinde kullanmayınız. Asla adında bir nokta kullanmamanızı şiddetle tavsiye ederim (sütun, tablo, görünüm, veritabanı vb.).
Güncelleme: Eksi "dash" eksi simmilar sorunlara neden olduğunu onaylayabilirim.
İşte olanlar:
SQL Server, sistem saklı yordamları gibi dahili kullanım için komut dosyalarını kullanır. Burada daha önce de belirtildiği gibi, kullandığınız komutlar bazen sizi adı parantez içine almaya zorlar ve bu (ciddi olarak microsoft?) Saklı yordamların kullanımı için uygun değildir (her zaman) .
Aslında, abonnement bilgilerini artık temizleyemiyorum, çünkü saklı yordam tüm veritabanlarında yineleniyor ve veritabanı adlarından tam olarak çıkmıyor. Bu yineleme, karmaşıklığı 8 SP'den fazlaya ekleyemedim.
Artı çoğaltma çakışmalarını düzenlemek için MMC veya komut dosyalarını kullanamıyorum . Adında bir nokta bulunan bir (One!) Veritabanına sahipseniz, bu sorunlar her yayında her zaman db'de ortaya çıkar.
Bunlar benim sahip olduğum olaylar. Karmaşık SQL eylemleri sql dilinde işlenir ve temel iyi ise, iyi çalışacaktır.
Veritabanınızı Microsoft Query (ODBC aracılığıyla) kullanarak bir excel sayfasına bağlamaya çalışırsanız, bağlanmak istediğiniz veritabanını seçmenize olanak sağlayan bir yapılandırma sihirbazı elde edersiniz. - aKzenT
Bu hatalar daha çok 3. parti yazılımlarda bulunabilir, bu yüzden hiçbir zaman sql sunucusundaki herhangi bir şeyin adında noktalar kullanmayın.
Aynı anlaşma: yabancı anahtar adında herhangi bir nokta bulunmamalıdır.
Böyle bir adı yeniden adlandırmanız gerekiyorsa, o zaman sp_renameişi yapmak için parantez kullanmanız gerekeceğini keşfettim (çünkü bir Yabancı anahtarını yeniden adlandırırken şemayı belirtmeniz gerekir).
Örnek:
sp_rename '[MySchema].[MyFKName.With.Dots]' 'NewFKName' 'OBJECT'Destekleri unutursanız, bir hata alırsınız: 15225
Tedarikçilerimizden biri şema adını tanıtmayı seçti: [System.Activities.DurableInstancing]. Veri yükleme aracımız bozuldu, bu yüzden onların gariplikleriyle başa çıkmak için daha fazla geliştirmeye sahibiz. Sadece yapma. Kullanın '-'.
-Bir alt çizgi kullanabiliyorken_ve adı köşeli parantez içine almak zorunda değilken neden bir çizgi kullanın ?