Büyük kimlik değerlerinden kaçınma nedenleri


17

Henüz kullanıcılar tarafından erişilemeyen bir web uygulaması üzerinde çalışıyoruz. Patronum, yeni oluşturulan kayıtların tabloda 100'den az kayıt olmasına rağmen 10.000'den fazla kimlik aldığını fark etti. Bir sebepten dolayı web arayüzünün gerçek kayıtlardan 100 kat daha fazla geçici kayıt oluşturduğunu (ve bunları sildiğini) ve bunun birkaç ay içinde aralık dışında kalmamızı sağlayabileceğini varsaydı.

Kimlik enflasyonunun nedeni hakkında doğru olduğunu düşünmüyorum (buna cevap verebilen meslektaş tatilde, bu yüzden kesin olarak bilmiyoruz), ama varsayalım. Bir bigint sütunu kullanmaktan nefret ettiğini ve kimlik sütununu otomatik olarak büyütmeyi durdurmamızı ve ilk "kullanılmayan" tamsayıyı seçen ve onu kimlik olarak kullanan sunucu tarafı kodu yazmamızı istediğini söyledi.

Ben küçük bir pratik deneyimi olan, küçük bir geliştirici rolünü dolduran bir bilgisayar bilimi yüksek lisans öğrencisiyim. Kuruluşumuzun tüm veritabanlarını yönetme ve çoğunu tasarlama konusunda yılların deneyimine sahiptir. Ben düşünüyorum o Bigint Kimlik DBMS işlevselliği taklit bir antipattern kokuyor korkulacak bir şey değildir ve bu, bu durumda yanlış olduğunu. Ama henüz yargılamaya güvenmiyorum.

Her pozisyon için ve her pozisyona karşı argümanlar nelerdir? Bir bigint kullanırsak ne gibi kötü şeyler olabilir ve tekerleğin otomatik arttırma işlevselliğini yeniden keşfetmenin tehlikeleri nelerdir? Her ikisinden de daha iyi olan üçüncü bir çözüm var mı? Kimlik yüz değerlerinin enflasyonundan kaçınmak istemesinin sebepleri ne olabilir? Ben de pragmatik nedenleri duymakla ilgileniyorum - belki bigint kimlikleri teoride çalışıyor, ama pratikte baş ağrısına neden oluyor?

Uygulamanın çok büyük miktarda veri işlemesi beklenmemektedir. Önümüzdeki birkaç yıl içinde 10.000 gerçek kayda ulaşacağından şüpheliyim.

Herhangi bir fark yaratırsa, Microsoft SQL sunucusu kullanıyoruz. Uygulama C # ile yazılmış ve Linq to SQL kullanır.

Güncelleme

Teşekkür ederim, mevcut cevapları ve yorumları ilginç buldum. Ama korkarım sorumu yanlış anladın, bu yüzden bilmek istediklerimi içeriyorlar.

Yüksek kimliklerin gerçek nedeni hakkında gerçekten endişelenmiyorum. Eğer bunu kendi başımıza bulamazsak, farklı bir soru sorabilirim. İlgilendiğim şey, bu davadaki karar sürecini anlamak. Bunun için lütfen uygulamanın günde 1000 kayıt yazacağını ve ardından bunların 9999'unu sileceğini varsayalım . Neredeyse böyle olmadığından eminim, ama patronum onun isteğini yaparken inandığı şey buydu. Öyleyse, bu varsayımsal koşullar altında, bigint kullanmanın veya kimlikler atayacak kendi kodumuzu yazmanın artıları ve eksileri ne olurdu (boşluklar olmadığından emin olmak için zaten silinmiş kayıtların kimliklerini yeniden kullanan bir şekilde)?

Asıl nedene gelince, bunun bir zamanlar başka bir veritabanından veri almak için kod yazdığımızdan, daha sonraki bir geçişin belirli bir ölçüde yapılabileceğine dair bir kavram kanıtı olarak olduğunu düşünüyorum. İş arkadaşımın ithalat sırasında aslında birkaç bin kayıt oluşturduğunu ve daha sonra sildiğini düşünüyorum. Bunun gerçekten böyle olup olmadığını doğrulamalıyım, ancak eğer öyleyse, harekete geçmeye bile gerek yok.


SM Ahasan Habib adlı kişinin codeproject.com/Tips/668042/…
RLF

Açıklayabilir misin? Yeni kimlikler 10000'den büyük değerler alıyor mu? Yoksa yeni kimliklerin 10000 boşluğu var mı? Gelecek uygulama yaşamında kaç kimliğe ihtiyaç olduğu tahmin ediliyor?
user2338816

1
Kullanılmayan ilk kimliği bulmakla ilgili olarak, Bill Karwin'in "SQL Antipatterns" kitabında bununla ilgili bir bölüm var. Yani evet, kesinlikle bir antipattern olarak görülebilir!
Thomas Padron-McCarthy

Yanıtlar:


24

Kodu görmeden ne olduğunu kesin olarak söylemek oldukça zordur. Her ne kadar büyük olasılıkla IDENTITYdeğer önbelleğe alınıyor olsa da, SQL Server yeniden başlatıldıktan sonra değerde boşluklara neden oluyor. Bununla ilgili bazı iyi cevaplar ve bilgiler için /programming/17587094/identity-column-value-suddenly-jumps-to-1001-in-sql-server adresine bakın .

Basit bir INTalan 2.147.483.647'ye kadar değerleri tutabilir. Gerçekte kimlik değerini -2.147.483.648'de başlatabilir ve 32 bitlik tam bir değer verebilirsiniz. 4 Milyar ayrı değer. Kullanacağınız değerlerin tükeneceğinden şüpheliyim. Başvurunuz varsayarsak olduğu eklenen her fiili satır için 1.000 değerleri tüketen, size başladı varsayarak 6 ay içinde kimlikleri dolmak üzere günde yaklaşık 12.000 satır her gün yaratıyor gerekiyordu IDENTITY0'dan değer ve bir INT kullanıyorlardı. Bir BIGINT kullanıyorsanız, günde 12.000 satır yazdıysanız ve satır başına 1.000 "değer" tüketerek değerlerin tükenmesinden önce 21 milyon yüzyıl beklemeniz gerekir.

Tüm bunları söyledikten sonra BIGINT, kimlik alanı veri türü olarak kullanmak istiyorsanız , bununla ilgili kesinlikle yanlış bir şey yoktur. Bu, tüm amaç ve amaçlar için, sınırsız bir değer kaynağı sağlar. INT ve BIGINT arasındaki performans farkı, modern 64 bit donanımda pratik olarak mevcut değildir ve örneğin NEWID()GUID'ler oluşturmak için kullanıldığında oldukça tercih edilir .

Eğer kimlik sütun için kendi değerlerinizi yönetmek istiyorsa, bir anahtar tablo oluşturmak ve yapmanın oldukça kurşun yol verebileceğini de bu soru üzerine cevaplar gösterilen yöntemlerden birini kullanarak: olmadan kilit tabloya eşzamanlı erişim Handling SQL Server'daki kilitlenmeler

SQL Server 2012+ kullandığınızı varsayarsak, diğer seçenek, SEQUENCEsütun için kimlik değerleri almak üzere bir nesne kullanmak olacaktır . Ancak, diziyi değerleri önbelleğe almayacak şekilde yapılandırmanız gerekir. Örneğin:

CREATE SEQUENCE dbo.MySequence AS INT START WITH -2147483648 INCREMENT BY 1 NO CACHE;

Patronunuzun “yüksek” sayıları olumsuz algılamasına cevaben, bunun ne fark yarattığını söyleyebilirim? Bir INTalan kullandığınızı varsayarsak , bir ile IDENTITYaslında IDENTITYat 2147483647değerini başlatabilir ve değeri "artırabilir" -1. Çünkü eğer bu kesinlikle bir 32 bitlik sayı beri kullanılan bellek tüketimi, performansı veya disk alanının hiçbir fark 4 bayt olursa olsun yapacak 0ya 2147483647. 0ikili, 0000000000000000000000000000000032-bit işaretli bir INTalanda saklanır . 2147483647dır-dir01111111111111111111111111111111- her iki sayı da hem bellekte hem de diskte tam olarak aynı miktarda alan kaplar ve her ikisi de işlemek için tam olarak aynı miktarda CPU işlemi gerektirir. Uygulama kodunuzu doğru bir şekilde tasarlamanız, önemli bir alanda saklanan gerçek numarayı saplantı haline getirmekten çok daha önemlidir.

(A) a gibi daha büyük kapasiteli bir kimlik sütunu kullanmak BIGINTveya (b) kimlik boşluklarını önlemek için kendi çözümünüzü yuvarlamak gibi avantaj ve dezavantajları sordunuz . Bu endişeleri cevaplamak için:

  1. BIGINTINTsöz konusu sütun için veri türü olarak değil . A kullanmak BIGINT, sütunun kendisi için hem diskte hem de bellekte iki kat depolama alanı gerektirir. Sütun, ilgili tablonun birincil anahtar dizini ise, tabloya eklenmiş her kümelenmemiş dizin de, BIGINTdeğeri INThem bellekte hem de diskte olmak üzere iki kat büyüklüğünde de depolar . SQL Server, verileri diskte 8KB sayfada saklar; burada "sayfa" başına "satır" sayısı, her satırın "genişliğine" bağlıdır. Örneğin, her birinde 10 sütun içeren bir tablonuz varsa, INTsayfa başına yaklaşık 160 satır depolayabilirsiniz. Bu sütunlar yerineBIGINTsütunlarında, sayfa başına yalnızca 80 satır depolayabilirsiniz. Çok fazla sayıda satıra sahip bir tablo için bu, tabloyu okumak ve yazmak için gereken G / Ç'nin belirli sayıda satır için bu örnekte iki katına çıkacağı anlamına gelir. Kabul, bu oldukça uç bir örnek - tek oluşan bir satır olsaydı INTveya BIGINTsütuna ve tek NCHAR(4000)sütunda, size bir kullanılmış olsun, sayfa başına tek bir satır elde (simplistically) olurdu INTya da BIGINT. Bu senaryoda, kayda değer bir fark yaratmaz.

  2. Kimlik sütunundaki boşlukları önlemek için kendi senaryonuzu yuvarlayın. Kodunuzu, kullanılacak "sonraki" kimlik değerini belirlemenin tablodaki diğer eylemlerle çakışmayacağı şekilde yazmanız gerekir. SELECT TOP(1) [ID] FROM [schema].[table]Safça çizgileri boyunca bir şey akla geliyor. Tabloya aynı anda yeni satırlar yazmaya çalışan birden fazla aktör varsa ne olur? İki oyuncu aynı değeri kolayca elde edebilir ve bu da yazma çatışmasına neden olabilir. Bu sorunun üstesinden gelmek, tabloya erişimi serileştirerek performansı azaltır. Bu sorun hakkında birçok makale yazılmıştır; Bu konuda arama yapmak için okuyucuya bırakacağım.

Buradaki sonuç şudur: Gereksinimlerinizi anlamanız ve uygulamanızın eşzamanlılık gereksinimlerinin yanı sıra hem satır sayısını hem de satır genişliğini doğru bir şekilde tahmin etmeniz gerekir. Her zamanki gibi It Depends ™.


4
+1 ama BIGINT'in alan gereksinimlerini atmazdım. Diskteki alan için değil, G / Ç ve bellekte boşa giden. Veri sıkıştırmasını kullanarak bunların çoğunu dengeleyebilirsiniz, böylece 2 milyarı aşana kadar BIGINT tipinin bruntunu gerçekten hissetmezsiniz. İdeal olarak sadece sorunu düzeltirlerdi (buna kendi başına bir hata demekten çekinmeyin) - insanlar boşlukları önemsememeli ve insanlar günde 15 kez sunucularını yeniden başlatmamalarına rağmen, her iki senaryo da oldukça yaygın ve çoğu zaman birlikte.
Aaron Bertrand

3
Çok geçerli noktalar, Aaron, her zamanki gibi. Ben zaten bir INT kullanmaya eğilimi olacaktır, çünkü BIGINT çok sayıda satır beklemedikçe hemen hemen tamamen aşırıya kaçıyor.
Max Vernon

Bir kimlik sütunu için bir BIGINT veri türünün, aynı anda yüz binlerce veya daha fazla bellekte olmadıkça bellek üzerinde çok fazla etkisi olmaz. O zaman bile, toplam satır boyutunun küçük bir kısmı olması muhtemeldir.
user2338816

2
@ user2338816 önemli olan - eğer tablo büyürse, hafızada çok şey olacaktır. Kimlik sütunu genellikle kümeleme anahtarı olduğundan, her dizindeki her satır için de fazladan 4 baytlık bir değerdir. Her durumda önemli olacak mı? Hayır. Yok sayılmalı mı? Kesinlikle hayır. Kimse çok geç olana kadar ölçeklenebilirlik hakkında bir ipucu vermez.
Aaron Bertrand

3
Eğer olsa yapmak ihtiyacınız olabilecek meşru bir beklentiye sahip bigintmuhtemelen önceden karar vermeden ziyade milyarlarca satır olan bir tabloya bu eklemek gerek için kendinize teşekkür edeceğiz.
Martin Smith

6

Yapılacak ana görev, geçerli değerin bu kadar yüksek olmasının nedenini bulmaktır.

SQL2012 öncesi bir test veritabanı hakkında konuştuğunuz varsayımından önce SQL Server sürümleri için en makul açıklama, bir yük testinin ardından bir temizleme işlemi olmasıdır.

SQL2012'den başlayarak en olası neden, SQL Engine'in birkaç yeniden başlatılmasından kaynaklanmaktadır (sağlanan ilk bağlantıda Max açıklandığı gibi).

Boşluğa bir test senaryosu neden oluyorsa, benim açımdan endişelenmem için bir neden yok. Ancak güvenli tarafta olmak için, uygulamanın normal kullanımı sırasında ve bir motorun yeniden çalıştırılmasından önce ve sonra kimlik değerlerini kontrol ederim.

MS'in her iki alternatifin de (izleme bayrağı 272 veya yeni SEQUENCE nesnesi) performansı etkileyebileceğini "komik" buluyor.

MS'nin bir sonraki "geliştirmelerini" kapsayacak şekilde güvenli tarafta olmak için INT yerine BIGINT kullanmak en iyi çözüm olabilir ...


Muhtemelen sorumu yanlış bir şekilde ifade ettim, ama sebebini bulmakla gerçekten ilgilenmiyorum. Yeniden görünmeyecek bir şey (bir test çalıştırmasının sonuçları) veya uygulamada, veritabanının dışında çözülebilecek kötü bir tasarım kararı olması olasılığı yüksektir. Mesele, deneyimli bir DBA'nın neden yüksek ID'leri kendi kimlik yönetimimizi devretmekten daha kötü veya kötü olarak değerlendireceğini anlamaktı.
rumtscho

2

Rumtscho, Günde sadece 1000 satır oluşturuyorsanız, karar vermek için çok az şey var - INT veri türünü bir Kimlik alanı ile kullanın ve onunla yapın. Basit matematik, uygulamanıza 30 yıllık bir yaşam döngüsü verirseniz (olası değil) günde 200.000 satıra sahip olabileceğinizi ve yine de bir INT veri türünün pozitif sayı aralığında olabileceğini söylüyor.

Sizin durumunuzda BigInt kullanmak aşırıya kaçarsa, uygulamanıza veya verilerinize ODBC aracılığıyla erişilirse (Excel veya MS Access'e getirilen gibi) de sorunlara neden olabilir, Bigint çoğu ODBC sürücüsünün çoğunu masaüstü uygulamalarına iyi çevirmez.

GUIDS'e gelince, ekstra disk alanı ve ekstra G / Ç dışında, sıralı olmayan tasarımla büyük bir sorun var, bu yüzden sıralı bir dizinin parçasıysa, her eklentinin dizinin yeniden gönderilmesini gerektirir. --Jim


NEWSEQUENTIALID () kullanmadığınız sürece GUID'ler hakkında iyi bir nokta - Hala katılıyorum, bu soruda belirgin olarak kullanmak için harika bir neden yok.
Max Vernon

1

Kullanılan değerler arasında bir boşluk var mı? Veya başlangıç ​​değerleri 10.000'dir ve bundan sonra 1 eklenir? Bazen numara müşterilere verilecekse, ilk sayı sıfırdan büyüktür, örneğin 1500 diyelim, bu nedenle müşteri sistemin "yeni" olduğunu anlamıyor.

Smallint yerine bigint kullanmanın dezavantajı, bigint'in "daha fazla disk alanı" kullandığı için, disk okurken her disk için daha az disk bloğu okursunuz. Satır alanınız küçükse, bu bir dezavantaj olabilir, eğer değilse, çok önemli değildir. Ayrıca, aynı anda çok fazla kaynağı sorgulamıyorsanız ve uygun dizinlere sahipseniz çok da önemli değildir.

Ve diğer yanıtta belirtildiği gibi, endekslerin tükenmesinden endişe ediyorsanız, endişelenmemelisiniz, bir milyoner işiniz olmadıkça smallint işleyebilir. "Kimlikleri kurtarmak" için bir mekanizma icat etmek pahalıdır ve yazılıma arıza noktaları ve karmaşıklık katar.

Saygılarımızla


2
OP hizmetin yeniden başlatılmasında boşluklar görüyor. Bunun nedeni bu . Ayrıca, bir smallint'in daha sonra düzeltmek için alacağı iş için kısa vadede iyi bir ödünleşme olduğunu düşünmüyorum.
Aaron Bertrand

@AaronBertrand aslında, başkalarının bu olasılığı önerdiklerinde bunu yanlış anladıklarından korkuyorum. Bu yüksek sayıların nedeni olmadığından eminim, ama öyle olsa bile, sebebi bulmaya çalışmıyordum, ancak önerilen çözümlere karşı ve önerilen çözümlere karşı hangi argümanların olabileceğini öğrenmeye çalışıyordum. Ayrıntılar için güncellememe bakın.
rumtscho

@rumtscho aslında bu cevap doğrudan sorunuzu ele almasa bile iyi bir noktayı vurgular: "'Kimlikleri kurtarmak için bir mekanizma icat etmek pahalıdır ve yazılıma hata noktaları ve karmaşıklık katar."
Doktor J

@DoktorJ Sana katılıyorum. Cevabı iptal eden kişiydim :) Sadece yanlış anlaşılmayı gidermek istedim, bu yüzden ilk yorumumu bıraktım.
rumtscho

1

Ben patronun olsaydı olurdu sen özetlenen iki senaryo her biri için en beklenmedik yüksek Kimliği değerleri için sebepler ilginizi ... Ben öyle anlıyorum:

  1. Önceki testler kimlik değerlerini artırdıysa - beklenen sayıda kayıt hakkındaki diğer yorumlarınız beni daha küçük bir anahtar türü önermek için zorlardı. Açıkçası, testin tablonun mevcut kullanım amacı için karakter dışı olması durumunda diziyi sıfırlamanın ve mevcut kayıtları yeniden numaralandırmanın mümkün olup olmadığını da düşünürdüm (çoğu bu aşırı kullanımı düşünür - 'bağlıdır').

  2. EĞER tabloya yazılan kayıtların çoğunluğu, ben yerine iki tablo kullanmayı düşünmeye eğilimli olacağını kısa bir süre sonra silinir; kayıtların uzun vadede tutulmadığı geçici bir tablo ve yalnızca kalıcı olarak oluşturacağımız kayıtların tutulduğu başka bir tablo tutulur. Yine, uzun vadeli kayıt sayısıyla ilgili beklentileriniz bana anahtar sütununuz için daha küçük bir tür kullanılmasını önermektedir ve günde birkaç kayıt, bir performans sorununu bir tablodan diğerine 'taşımak' için neredeyse hiç neden olmayacaktır. bir. Senaryo olmadığından şüpheleniyorum, ancak bir alışveriş web sitesinin bir Basket / BasketItem sürdürmeyi tercih edebileceğini ve bir sipariş verildiğinde verilerin Order / OrderItem setine taşındığını hayal edin.

Özetle; bence BIGINTs korkmak zorunda değil, ama birçok senaryo için açıkçası gereksiz yere büyük. Tablo asla büyük olmazsa, tür seçiminizde aşırıya kaçma olduğunu asla anlamayacaksınız ... ancak milyonlarca satır ve daha küçük olabildiklerinde BÜYÜK olan birçok FK sütununa sahip tablolarınız olduğunda - o zaman türleri daha muhafazakar bir şekilde seçilmiştir (yalnızca anahtar sütunları değil, tüm ön anahtar sütunlarını ve sakladığınız tüm yedeklemeleri göz önünde bulundurun!). Disk alanı her zaman ucuz değildir (SAN diskini yönetilen konumlarda düşünün - yani disk alanı kiralanır).

Özünde ben veri türü seçiminize dikkatli değerlendirilmesi için sürüyorum hep ziyade bazen . Her zaman kullanım kalıplarını doğru bir şekilde tahmin edemezsiniz, ancak bence kural olarak daha iyi kararlar vereceksiniz, daha sonra her zaman 'daha büyük daha iyi' olduğunu varsayalım. Genel olarak gerekli ve makul değer aralığını içerebilecek en küçük türü seçiyorum ve değerin öngörülebilir gelecek için bu tipe uymasının muhtemel olduğunu düşünüyorsanız, INT, SMALLINT ve hatta TINYINT'i dikkate alacağım. Bununla birlikte, daha küçük türlerin KİMLİK sütunları ile kullanılması olası değildir, ancak anahtar değerlerin manuel olarak ayarlandığı arama tablolarıyla mutlu bir şekilde kullanılabilir.

Son olarak, insanların kullandığı teknolojiler beklentilerini ve cevaplarını önemli ölçüde etkileyebilir. Bazı araçların, örneğin işlem başına kimlik aralıklarını önceden ayırması gibi, aralıklarda boşluklara neden olma olasılığı daha yüksektir. Buna karşılık @DocSalvager, patronunuzun bakış açısını yansıtan kapsamlı bir denetlenebilir dizi önerir; Şahsen hiçbir zaman tam olarak otorite seviyesine ihtiyaç duymadım - kimliklerin sıralı olduğu ve genellikle boşluksuz olduğu genel kural, destek durumlarında ve sorun analizinde benim için inanılmaz derecede faydalı oldu.


1

bigint kullanmanın ya da kimlikler atayacak kendi kodumuzu yazmanın artıları ve eksileri ne olurdu (boşluklar olmadığından emin olmak için önceden silinmiş kayıtların kimliklerini yeniden kullanan bir şekilde)?

bigintKimlik olarak kullanmak ve boşluklarla yaşamak:

  • hepsi yerleşik işlevsellik
  • kullanıma hazır olacağından emin olabilirsiniz
  • o zamandan beri yer israf edecek int hala 2M gün verilerle ilgili verecekti; daha fazla sayfa okunmalı ve yazılmalıdır; endeksler daha da derinleşebilir. (Ancak bu ciltlerde bu önemli bir endişe kaynağı değildir).
  • bir vekil anahtar sütunun anlamı anlamsızdır, bu nedenle boşluklar iyidir. Kullanıcılara gösteriliyorsa ve boşluklar önemli olarak yorumlanıyorsa, yanlış yapıyorsunuz demektir.

Kendininkini yuvarla:

  • geliştirme ekibiniz tüm geliştirme ve hata düzeltme çalışmalarını sonsuza kadar yapacaktır.
  • sadece kuyrukta mı yoksa ortasındaki boşlukları mı doldurmak istiyorsun? Tartışmak için tasarım kararları.
  • her yazmanın, aynı yeni kimliği edinmesini veya eş zamanlı süreçlerin facto sonrası çatışmaları çözmesini önlemek için güçlü kilitler yayınlaması gerekir .
  • en kötü durumda, rowid = 1 silinirse boşlukları kapatmak için tablodaki her satırı güncellemeniz gerekir. Bu, eşzamanlılığı ve performansı, tüm basamaklı yabancı anahtar güncellemelerini vb.
  • tembel ya da istekli boşluk doldurma? Bu gerçekleşirken eşzamanlılığa ne olur?
  • herhangi bir yazma = ek yükten önce yeni kimliği okumak zorunda kalacaksınız.
  • etkin boşluk bulmak için kimlik sütununda bir indeks gerekecektir.

0

PK'larınız için INT'nin üst eşiğini vurmaktan gerçekten endişe ediyorsanız, GUID'leri kullanmayı düşünün. Evet, 16 bayt vs 4 bayt olduğunu biliyorum, ancak disk ucuz.

İşte artıları ve eksileri hakkında iyi bir yazı .


4
+1 çünkü bu bir çözümdür, ancak "disk ucuzdur" un nedenlerini dikkatlice tartılmadan GUID'leri kullanmak için bir neden olmadığından Aaron'un Max'in cevabı hakkındaki yorumuna bakın .
Jack Douglas

1
İşte bir geliştirici yerine bir SQL Server dizini ve mimarlık uzmanından daha iyi bir yazı
Aaron Bertrand

Oh, ve tabii ki NEWID ()
Max Vernon

1
Patronum, sadece yüksek görünmeleri nedeniyle yüksek değerlere itiraz ediyor gibi görünüyor. Bu sorunun bana daha fazla itiraz göstereceğini umuyorum, ancak bu onun ana argümanlarından biriyse, muhtemelen GUID'lere daha da olumsuz tepki gösterecektir.
rumtscho

1
@ rumtscho Patronunuza yedek bir numaranın sadece anlamsız bir sayı olduğunu (numaranın "boyutu" alakasız olduğunu ve bir sekanstaki boşlukların doğal ve büyük ölçüde kaçınılmaz olduğunu söyleyin.
Aaron Bertrand

0

RDBMS Birincil Anahtarları (sütun genellikle 'Kimlik' olarak adlandırılır)
RDBMS otomatik büyütme sütunlarında (alanlarda) boşluklardan kaçınılamaz. Öncelikle benzersiz PK'ler oluşturmak için tasarlanmıştır. Performans için, başlıca ürünler bunları gruplar halinde tahsis eder, bu nedenle çeşitli normal çalışma hataları için otomatik kurtarma mekanizmaları sayıların kullanılmamasına neden olabilir. Bu normal.

Kırılmamış diziler
genellikle kullanıcılar tarafından beklenen gibi bir kırılmamış sıra numarası ihtiyaç, programlı atanır ve gereken ayrı bir sütun olmalıdır değil PK olun. Böylece, bu 1000 kaydın hepsi bu sütunda aynı sayıya sahip olabilir.

Kullanıcılar neden kesintisiz diziler ister?
Eksik sıra numaraları, her türlü denetimde ortaya çıkan en temel hata işaretidir. Bu "Defter Tutma-101" prensibi her yerde bulunur. Bununla birlikte, el ile tutulan az sayıda kayıt için işe yarayan, veritabanlarındaki çok sayıda kayda uygulandığında ciddi bir sorun vardır ...

İlişkisiz kayıtlar için anahtar değerlerin yeniden
kullanılması veritabanını geçersiz kılar "İlk kullanılmayan tamsayı" kullanılarak, gelecekte bir noktada, orijinal ile ilgisiz kayıtlar için bir sayının yeniden kullanılması olasılığı ortaya çıkar. Bu, veritabanının gerçeklerin doğru bir temsili olarak güvenilmez olmasını sağlar. Bu otomatik büyütme mekanizmalarının hiçbir zaman asla bir değeri yeniden kullanamayacak şekilde tasarlanmasının temel sebebidir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.