Açıkça benzersiz bir kimlik oluşturan Kimlik Sütunları veya UDF?

Açıkça benzersiz bir kimlik üreten bir UDF dışında PRIMARY KEYbir Kimlik Sütunlarından bir çıkış yapmanın daha iyi olup olmadığı konusunda bir tartışmanın ortasındayım .

• Kimlik Sütunu'nu tartışıyorum.
• Ortağım değerleri elle oluşturmayı savunuyor,
  • UDF'yi UDF'ye sahip olabileceğimiz başka bir masaya koyarak
    • kaynağı kilitle
    • ID_Valuetarafından adlandırılan bir alanla kimlik tablosunu artırma1
    • bunu global benzersiz tanımlayıcı olarak kullan
  • Veya id+1eklerken tablonun
  • Verileri tanımlama kısıtı olmayan sunucular ve / veya ortamlar arasında taşımanın daha basit olması; Verilerin olduğu bir DB'den benzer bir DB'ye geçiş, diyelim evreleme veya kukla veriler sağlar. Üretim dışı testler için, dünden tüm testlere geçmeye kadar tüm kayıtları çekmek isteyebiliriz.

Hangi uygulama daha anlamlı?

Meslektaşın bir salak.

Çözüm ölçeklenebilir olmayacak, UDF eşzamanlı değil (bununla aynı neden ). Ve çok satırlı eklerle nasıl başa çıkacaksınız: bu satır başına bir UDF çağrısı gerektirir

Ve diğer RDBMS'ye geçiş gerçek hayatta sık sık gerçekleşmez ... SQL Server'ı şimdi kullanamayabilir ve Oracle'da sıralar kullanabilir ve uzaklaşmadığınızı umabilirsiniz.

Düzenle:

Güncellemeniz, hareketli verilerin üretim dışı veritabanlarını yenilemek için olduğunu belirtir.

Bu durumda, yenileme sırasında kimlik sütunlarını yoksayarsınız. Üretim dışı yüklemeyi kolaylaştırmak için uygulamanızdan ödün vermezsiniz. Veya kimlik değeri değişikliklerini izlemek için geçici tabloları kullanın.

Veya süreçleri kullanın: test sistemimizi her gece üretimden yeniliyoruz, bu da sorunu tamamen önlüyor. (Ve ürün yedeklememizin de geri yüklenmesini sağlar)

Bir kimlik değeri kullanın. Kendi dizi tablonuzu ve dizi değerlerinizi oluşturmak çok fazla yük alır ve sayı üretmeye çalışırken çok fazla kilitleme ve engellemeye neden olur.

Kimlik bir nedenden dolayı var, onu kullan.

SQL Denali ortaya çıktığında, kimlikten daha verimli olacak dizileri destekleyecektir, ancak kendiniz daha verimli bir şey oluşturamazsınız.

Kayıtları bir ortamdan başka bir ortama taşımak için, ekleme yaparken IDENTITY_INSERT'i AÇIN veya SSIS'deki kutuyu işaretleyin.

Kimlik sütunu bana iyi geliyor. Verileri sunucular arasında taşımanın neden zor olduğuyla ilgili mantığı izlediğimden emin değilim.

Her satırın benzersiz benzersiz bir kimliğe sahip olmasını istiyorsanız, bir UUID kullanabilirsiniz, ancak küresel benzersizliğin gerekli olduğundan emin değilseniz bunu yapmazdım - genellikle değil. UUID'leri ids olarak kullanmak performansı düşürecek, disk alanı gereksinimlerini artıracak ve hata ayıklamayı zorlaştıracaktır.

Basit sayısal kimlikler için, kimlikle gidin ve bunları manuel olarak oluşturmanın tüm sorunlarını unutun.

Her zaman PK olarak bir kimlik kullanan ve bir tür sütunu ve diğer tüm bilgileri içeren bir "süper tablo" oluşturabilirsiniz. Yeni bir kimliğe ihtiyacınız olduğunda (farklı tablolarda benzersiz IDS demek istediğinizi varsayarsak) bu tabloya SCOPE_IDENTITY()yerleştirin ve ardından ihtiyacınız olan gerçek tabloya yerleştirin.

Temel olarak bir tablo oluşturun: MasterIDs bir kimlik PK ile, kendi Table1 bir satır eklemek, gerektiğinde INSERT INTO MasterIDsve kullanarak bu satırın tarafından üretilen kimlik almak SCOPE_IDENTITY()ve sonra içine yerleştirin Table1 olarak PK bu değeri kullanarak.

Tablo1 , kimlik dışı bir int PK'ye sahip olacaktır. Table2, vb eklemek için aynı işlemi yapardınız. SQL Server'ın daha sonra diğer tablolarınızda kullanabileceğiniz MasterIDs tablosundaki kimlik değerlerini yönetmesine izin verin . MasterID'ler tür gibi başka tablolar içerebilir (böylece hangi tablo, Table1 veya Table2, vb. Bu kimlik değerini kullanır biliyor olabilirsiniz.

Yabancı anahtar kısıtlamalarını doğru bir şekilde kullandığınız sürece (basamaklı, güncelleme vb.) Bir kimlik alanı kullanmakta iyi olacaksınız. Bu durumda diğer çözüme gerçekten bir avantaj görmüyorum.

Kimlik, senaryonuza uyacak şekilde oluşturuldu. Hepsini bir arada tutan sunucu / ortam veri alışverişi için çoğaltma gibi araçlarınız var.

Bir SQL Server identitysütununu normal bir intalanla değiştirdiğim ve kendimi kontrol ettiğim bir iş parçasını bitirdim .

Oldukça etkileyici performans artışları gördüm. OP'nin aksine, kimliği oluşturmak için bir UDF'm yok. Ancak ilke hemen hemen aynıdır: Yazılımın kimlik havuzunu koruyan bir kısmı vardır. Onlar bittiğinde bir sonraki için veritabanını sorgulayarak başka bir parti alır Düşük değer ve sonrakine artışlarla bu High .

Bu, toplu işleri veritabanına göndermeden ve kimliğin yeni eklenmesi için (kimlik sütunlarının gerektirdiği) ekstra dönüşler olmadan daha büyük toplu iş göndermeden önce kimlikler oluşturmamıza ve ORM'deki bir işlem dışındaki tüm varlıkları ilişkilendirmemize olanak tanır.

Kimlik tablosunda birden fazla satır var. İsterseniz belirli aralıkları kullanmamıza izin veriyoruz. örneğin, silinen blokları ve negatif kimlikleri yeniden kullanmak için.

Kimliği yıllardır kullanıyorum ve kimlik numarasını UNIQUEIDENTIFIER ile değiştirmeyi ciddi olarak düşünüyorum. Birisi kompakt bir db olarak tasarlamışsa veri türünü değiştirmeniz gerektiğinde bir kabus ve bir sütuna kimlik eklemeniz gerekiyorsa kabus, aynı zamanda kimlik sütununu güncelleyemezsiniz. Bir int koyduğunuzu ve veritabanınızın 2 milyar rekorun üzerine çıktığını, yine kabusun değişeceğini düşünün (FK'leri düşünün)! Kimlik ile herhangi bir şeyi değiştirmek bir kabustur ve bigint koymadıkça ölçek dostu değildir! UNIQUEIDENTIFIER vs Identity = kolaylık ve sağlamlık vs belki de gözle görülür performans artışı (kıyaslama yapmadı).

Güncelleme: Gördüğüm sonra bu kesinlikle uniqueIdentifier doğru eğiliyorum. Bu, bigint kimliğinin gerçek bir faydası ve UNIQUEIDENTIFIER için bir sürü fayda göstermiyor! SQL Server'ın farklı sürümleri farklı bir sonuç verebilir. Tüm veritabanlarında ve sistemlerde benzersiz bir kimliğe sahip olmanın güzelliği vardır (sağlamlık)! Verileri istediğiniz gibi taşıyın, kopyalayın, dönüştürün! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/