Her tablonun birincil anahtarı olmalı mı?

Bir veritabanı tablosu oluşturuyorum ve ona atanmış bir mantıksal birincil anahtar yok. Yani, birincil anahtar olmadan bırakmayı düşünüyorum, ama biraz suçlu hissediyorum. Yapmalımıyım?

Her tablonun birincil anahtarı olmalı mı?

Kısa cevap: evet .

Uzun cevap:

• Masanızın bir şeye katılabilir olması gerekir
• Tablonuzun kümelenmesini istiyorsanız, bir tür birincil anahtara ihtiyacınız vardır.
• Tablo tasarımınızın birincil bir anahtara ihtiyacı yoksa, tasarımınızı yeniden düşünün: büyük olasılıkla bir şey eksiksiniz. Neden aynı kayıtları tutmalı?

MySQL'de, InnoDB depolama motoru, açıkça belirtmediyseniz her zaman birincil bir anahtar oluşturur, böylece erişiminiz olmayan ekstra bir sütun oluşturur.

Birincil anahtarın birleşik olabileceğini unutmayın.

Çoktan çoğa bağlantı tablonuz varsa, bağlantıda yer alan tüm alanlarda birincil anahtarı oluşturursunuz. Böylece, bir bağlantıyı tanımlayan iki veya daha fazla kaydınız olmadığından emin olursunuz.

Mantıksal tutarlılık sorunlarının yanı sıra, çoğu RDBMS motoru bu alanları benzersiz bir dizine dahil etmekten fayda sağlayacaktır.

Ve herhangi bir birincil anahtar benzersiz bir dizin oluşturmayı içerdiğinden, bunu bildirmeli ve hem mantıksal tutarlılık hem de performans elde etmelisiniz.

Benzersiz veriler üzerinde neden her zaman benzersiz bir dizin oluşturmanız gerektiğini öğrenmek için blogumda bu makaleye bakın:

• Bir indeks UNIQUE yapma

Not: Birincil anahtara ihtiyaç duymadığınız bazı çok, çok özel durumlar vardır.

Çoğunlukla yok günlük masaları yer almaktadır herhangi performans nedenleriyle endeksler.

Birincil anahtara sahip olmak her zaman en iyisidir. Bu şekilde ilk normal formu karşılar ve veritabanı normalleştirme yolu boyunca devam etmenizi sağlar .

Başkaları tarafından belirtildiği gibi, birincil anahtarın olmamasının bazı nedenleri vardır, ancak birincil anahtar varsa çoğu zarar görmez

Hemen hemen birincil anahtar olmadan bir tablo oluşturduğumda, bir masaya ihtiyacım olmayacağını düşünerek, geri dönüp bir tane ekledim. Şimdi birincil anahtar olarak kullandığım otomatik oluşturulan kimlik alanı ile birleştirme tablolarımı bile oluşturuyorum.

Birkaç çok nadir durum (muhtemelen çoktan çoğa ilişki tablosu veya geçici olarak çok miktarda veri toplu olarak yüklemek için kullandığınız bir tablo) dışında şunu söyleyebilirim:

Birincil anahtarı yoksa, tablo değildir!

üzüm posası

Sadece ekleyin, daha sonra yapmadığınız için üzgün olacaksınız (seçme, silme. Bağlama, vb.)

Bu masaya başka masalara katılmanız gerekecek mi? Bir kaydı benzersiz bir şekilde tanımlamanın bir yolunu mu arıyorsunuz? Cevabınız evet ise, birincil bir anahtara ihtiyacınız vardır. Verilerinizin, müşteri olan kişilerin adlarını içeren bir müşteri tablosu gibi olduğunu varsayın. Doğal bir anahtar olmayabilir, çünkü bu Sally Smith'in bu Sally Smith'ten farklı olup olmadığını belirlemek için adreslere, e-postalara, telefon numaralarına vb. İhtiyacınız vardır. Sally Smith'in John Jones ile evlendiğini ve Sally Jones haline geldiğini varsayalım. Masanın üzerinde yapay bir anahtar yoksa, adı güncellediğinizde, sadece bir tanesi evlenmiş ve adını değiştirmiş olsa bile, 7 Sally Smith'i Sally Jones olarak değiştirdiniz.

Doğal bir anahtarınız olmadığını söylüyorsunuz, bu nedenle benzersiz yapmak için herhangi bir alan kombinasyonunuz yok, bu da yapay anahtarı kritik hale getiriyor.

Doğal bir anahtarım olmadığında buldum, yapay bir anahtar veri bütünlüğünü korumak için mutlak bir zorunluluktur. Doğal bir anahtarınız varsa, bunu anahtar alanı olarak kullanabilirsiniz. Ancak kişisel anahtar, doğal anahtar bir alan olmadığı sürece, doğal anahtarda yapay anahtar ve benzersiz bir dizin tercih ederim. Eğer içeri sokmazsan daha sonra pişman olursun.

Her masada bir PK olması iyi bir uygulamadır, ancak bu bir zorunluluk değildir. Büyük olasılıkla, ihtiyacınıza göre benzersiz bir dizine ve / veya kümelenmiş bir dizine (PK ya da değil) ihtiyacınız olacaktır.

Çevrimiçi Kitaplar'daki (SQL Server için) Birincil Anahtarlar ve Kümelenmiş Dizinler bölümlerine göz atın

" PRIMARY KEY kısıtlamaları, tablodaki bir satırı benzersiz olarak tanımlayan değerlere sahip sütunu veya sütun kümesini tanımlar. Tablodaki iki satır aynı birincil anahtar değerine sahip olamaz. Birincil anahtardaki hiçbir sütun için NULL giremezsiniz. birincil anahtar olarak küçük, tamsayı bir sütun kullanmanızı öneririz. Her tablonun birincil anahtarı olmalıdır. Birincil anahtar değeri olarak nitelenen bir sütun veya sütun birleşimi, aday anahtar olarak adlandırılır. "

Ancak, şunu da kontrol edin: http://www.aisintl.com/case/primary_and_foreign_key.html

Önerilen cevaba katılmıyorum. Kısa cevap: HAYIR .

Birincil anahtarın amacı, başka bir tabloyla ilişki oluşturmak için tablodaki bir satırı benzersiz olarak tanımlamaktır. Geleneksel olarak, bu amaçla otomatik olarak artırılan bir tam sayı değeri kullanılır, ancak bunun varyasyonları vardır.

Bununla birlikte, örneğin, böyle bir anahtarın varlığının basitçe gerekli olmadığı ve sadece belleği kapladığı zaman serisi verilerini günlüğe kaydetmek vardır. Bir satırı benzersiz yapmak sadece ... gerekli değildir!

Küçük bir örnek: Tablo A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Birincil Anahtar gerekmez.

Tablo B: Kullanıcı

Columns: Id, FirstName, LastName etc. 

LogData tablosuna "yabancı anahtar" olarak kullanılabilmesi için Birincil Anahtar (Id) gerekir.

NET'te gridview'in bazı özelliklerini kullanmak için gridview'ın hangi satırın güncellenmesi / silinmesi gerektiğini bilmesi için birincil bir anahtara ihtiyacınız olduğunu biliyorum. Genel uygulama, birincil anahtar veya birincil anahtar kümesine sahip olmalıdır. Ben şahsen öncekini tercih ederim.

Gelecekte bunu kanıtlamak için gerçekten yapmalısınız. Eğer çoğaltmak istiyorsanız, buna ihtiyacınız olacak. Başka bir masaya katılmak istiyorsanız (ve gelecek yıl sürdürmek zorunda olan fakir aptalların) hayatınız çok daha kolay olacaktır.

Açık deniz geliştirme ekibi tarafından oluşturulan uygulamanın sürdürülmesinde rol oynuyorum. Şimdi özgün veritabanı şeması bazı tablolarda PRIMARY KEYS içermiyor çünkü uygulamada her türlü sorunları yaşıyorum. Bu yüzden lütfen zayıf tasarımınız nedeniyle diğer insanların acı çekmesine izin vermeyin. Tablolarda birincil anahtarların bulunması her zaman iyi bir fikirdir.

Her zaman birincil bir anahtarım var, başlangıçta bunun için henüz bir amacım olmasa bile. Sonunda bir tabloya sahip olmayan bir PK'ya ihtiyacım olduğunda birkaç kez oldu ve daha sonra koymak her zaman daha fazla sorun. Ben her zaman bir dahil olmak üzere bir ters daha fazla olduğunu düşünüyorum.

Kısacası, hayır. Ancak, belirli istemci erişimi CRUD işlemlerinin gerektirdiğini unutmayın. Gelecekteki prova işlemleri için daima birincil anahtarları kullanma eğilimindeyim.

Hazırda Bekletme modunu kullanıyorsanız, birincil anahtar olmadan bir Varlık oluşturmak mümkün değildir. Düz sql / ddl komut dosyalarıyla oluşturulan varolan bir veritabanıyla çalışıyorsanız ve birincil anahtar eklenmediyse, bu sorunlar sorun oluşturabilir