Kimlik sütununun yeniden tohumlanması: ne zaman gerekli?

Üniversitedeki son derslerden birinde (öğrenciyim), öğretim görevlisi bizden bir veritabanı (önemliyse MySQL Sunucusu) ve veritabanını veri kaynağı olarak tüketecek küçük istemci uygulaması geliştirmemizi istedi.

Şartlardan biri, (her tabloda PK olan) kimlik sütununun sıralı olması gerektiğiydi, çünkü bu iyi bir uygulamadır (öğretim görevlisi kelimelerine göre). Yani, tablo satırı silindiğinde, PK'nın sonraki eklerde yeniden kullanılması gerekir. RDBMS, PK'ler ve kimlik sütunları hakkında ortalama bilgiye sahibim. Anladığım kadarıyla, bu kimlik sütunu, DB'nin satırları eklerken otomatik olarak PK'ler oluşturmasına izin vermenin bir yoludur. Ve kimlik sütunu değeri, hiçbir şekilde (doğal anahtar olmadığı sürece) satır nitelikleriyle ilişkili olmayacaktır.

Bu gereksinim (kesinlikle sıralı kimlik sütunu) benim için şüpheliydi. Kimlik sıralı değilse (silmelerin neden olduğu boşluklarla) öğretim görevlisine neyin yanlış olduğunu sormaya çalıştım, ancak "kullanıcılar için uygun ve veritabanını koruyan DB yöneticileri için yararlı" gibi çok soyut bir cevap aldım. Belirli bir örnek yok. "Kullanıcılar için uygun" argümanı kulağa hoş geliyor, çünkü iş alanında hiçbir anlamı yok.

Bu yüzden bu nedenlerin gerçek olup olmadığını merak ediyorum? Kimlik sütunu yeniden kullanımı gerektiğinde (kimlik alanı tükendiğinde) yalnızca bir vakayı düşünebilirim. Kimlik sütunu türü, yanlış diyelim basit seçildi Fakat bu daha tasarım konudur intyerine bigintveya uniqueidentifiermasa milyar satır içerdiğinde. Bir kimlik sütununun kümelenmiş bir dizin olduğunu varsayalım: Kimlik sütunundaki boşluklar dizin performansını etkileyebilir mi? Belki farkında olmadığım her silme işleminden sonra otomatik kimlik sütununun yeniden tohumlanmasının başka gerçek dünya nedenleri vardır?

Şimdiden teşekkürler!

Yani, tablo satırı silindiğinde, PK'nın sonraki eklerde yeniden kullanılması gerekir.

Öğretim elemanınız hangi evrenden geliyor?

Bu son derece verimsiz. Bunu yapmaya çalışırsanız, performans beklentilerinizi 10 kat azaltırsınız.

Denetim nedenleriyle boşluksuz sayılara ihtiyacınız varsa, bunları doğrudan veritabanı araçlarından değil, açıkça oluşturun. Ve asla satırları silmeyin, ancak "silinmiş" olarak işaretleyin. Bu, sorguların dağınıklığına katkıda bulunacaktır, çünkü bu tür satırları görmezden gelmeleri gerekecektir.

MySQL'de, InnoDB PRIMARY KEYher tablo için benzersiz bir varlığın olmasını gerektirir . Ancak bu gereksinimin kapsamıdır. Anahtar bir dize bile olabilir.

Boşluklar , kullanıcılar ve DBA'lar için bir kolaylıktır , rahatsızlık vermez .

Boşluğun elverişli olduğu bir durumu düşünebilirim - bir seferde 100 satırlık gruplara ayrılma. Ancak kullanımı basit bir çözüm var LIMIT 100,1.

Boşlukların performans üzerinde sıfır etkisi vardır. Bu, sayısal olmayan dizinleri içerir. Ve benzersiz olmayan dizinler. Ve bileşik endeksler.

Elbette, kimlikleri bitebilir. Sanırım MySQL kullandığım yaklaşık yirmi yılda iki kez olduğunu gördüm. Bir asteroit çarpması konusunda endişelenebilirim. Geceleri uyanık tut listemde düşük.

Boşluklar (en azından) den meydana gelir: INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(açık ya da bağlı çökmesine), (Galera ve Grup Çoğaltma dahil) Çok ana çoğaltma. Gerçekten bunlar için geçici çözümler bulmak ister misiniz ?!

Öğretim elemanının şüpheli olduğunu söylediği başka bir şeyi aklımızı kontrol etmekten çekinmeyin.

Bir kimlik değerinin tekrar kullanılması, genel olarak cesaret kırılmalıdır. Değer tamamen dahili olarak kullanılır, bu durumda gerçek değeri önemsizdir veya harici olarak da kullanılır, bu durumda değerin yeniden kullanılması büyük olasılıkla yanlış tanımlamaya yol açar.

Açıkça bir fatura veya satınalma siparişi numarasını ele alalım, bunlar kolayca bir kimlik sütunundan gelebilir ve harici olarak gösterilebilir, ancak bunları kesinlikle bu nedenle tekrar kullanmak istemezsiniz. Her ikisi de karışmak istemediğiniz belirli işlemlere atıfta bulunur.

Bu tür sorunların çözümü şirketler birleştiğinde veya satın alındığında büyük bir zorluk olabilir. Bu tür sorunları bilerek mi oluşturuyorsunuz? Akıllıca değil.

PK kimlik değerlerinin yeniden kullanılmasının sorunları vardır ve genellikle bundan kaçınılmalıdır.

İlk olarak, auto_increment sütunlarının uygulanması boşluksuz olma garantisi vermez. Gerçekten, bir eki otomatik artış sütununa geri alırsanız boşluklar oluşur.

İkinci olarak boşluk kimliği silinmemiş mevcut verilere atıfta bulunabilir (eksik FK kısıtlamaları nedeniyle). Sistemin dışında iletilen üye numaralarına çeviri yaparlarsa, bu potansiyel iş kimliği riskleri oluşturur.

Üçüncüsü, bigint unsignedson derece yüksek bir ekleme oranı göz önüne alındığında bile kimliklerinizin önemli bir süre tükenmeyecektir.

Boşluklarla ilgili en büyük acı, bir denetim kusuru konusunda ısrar eden denetçilerden geliyor. DBA'lar için boşlukların varlığını ve nedenini biliyorlar.

Bir başkasının PK'yi yeniden kullanmanın kötü bir fikir olduğu yönündeki yorumlarını tekrarlamayacağım, ancak bir kimlik sütununun yeniden tohumlanması gereken zamanlarda karşılaştım.

PK endeksinin kendisinin bozulması.

Bu MS-SQL ve yıllar önce, ama yine de alakalı olduğunu kabul etti. Yıllar önce çalıştığım şirket için, biri müşteriler tarafından kullanılmak için çok eski olduktan ve daha sonra bir dolaba yapıştırdıktan sonra 150'den fazla uzak konumumuzda PC'leri sunucu olarak yeniden kullanmanın iyi bir fikir olacağını düşündü. havalandırma olmadan. Ne zaman hayır Çünkü hepimiz biliyoruz ki, 120+ çalışan görev kritik veritabanlarına sahip küçük bir odada önemsiz 10 yaşındaki bir bilgisayar yığını sadece iyi şeylerle sonuçlanabilir. % 40 başarısızlık oranları gibi ve ben kariyer seçimimi yeniden düşünüyoruz. Verileri şirket merkezine geri göndeririz, ancak çoğu zaman bu başarısızlıklar veritabanlarında kötü şeylerin ortaya çıkmasına neden olur. Bunlardan biri, veritabanını ve çoğaltma işlemini ele geçirecek bozuk dizinlere sahip veritabanı idi. Bu harika ortamda iki kez, çoğaltmayı düzeltmek için tek çözüm dizinleri yeniden oluşturmak ve daha sonra çoğaltmayı yeniden kurmaktı. Sunucuları daha sonra tamamen terk etmeden önce değiştirdik.