Bir-bir tablo ilişkisi kullanmanın avantajları nelerdir?

8 Cevap php

Sadece bir tablodaki tüm verileri kaydetmek yerine bir tek-bir tablo ilişkisi kullanmanın avantajları nelerdir? Anlıyorum ve adlandırmasını kullanmak, özellikle bir-çok, çok-bir, ve çok-çok her zaman, ama bir tek-bir ilişki uygulanması sıkıcı ve gereksiz bir görev gibi görünüyor yararlanmak (php) ile ilgili sözleşmeler için veritabanı tabloları nesneleri.

Ben net veya bir-bir ilişkinin iyi bir gerçek dünyadan bir örnek kaynağı olabilir bu sitede bir şey bulamadı. İlk başta ben, iki tabloya, örneğin, bir profil sayfalarında 'Hakkımda' ve bir tür giriş / parola, vb gibi özel bilgileri içeren ama neden gitmek gibi bir içeren genel bilgiler 'users' ayırmak için mantıklı olacağını düşündüm Sadece hangi alanların yine bu tablodan seçmek seçebilirsiniz zaman gereksiz kullanan tüm sorun üzerinden KATILDI? Ben kullanıcının profil sayfasını görüntüleyen yaşıyorum, açıkçası ben sadece aboutme vb id, kullanıcı adı, e-posta, SEÇ olur ve alanları kendi özel bilgi içermeyen.

Herkes bir-bir ilişkilerinin bazı gerçek dünya örnekleri ile beni aydınlatmak ister?

8 Cevap

Ben uygulama db yapısını bozmadan, mevcut uygulamalarda bazı özellikleri genişletmek için bir ilişki için bir kullandım. Bu extending existing db tables için dikkat çekmeyen bir yoldur.

, Bir-bir ilişki kullanmak için bir başka neden hiyerarşi içinde her sınıf bir tablo vardır ki, Class Table Inheritance uygulanması için, ve bir nesne onun üst sınıf masa, yaptığı tablo sınıfında karşılık gelen bir satır vardır Onun grandparent sınıf tabloda vb.

Bakınız, örneğin doktrini 2-Class Table Inheritance Page

İşte iki, ben diğerleri daha yayınlayacağız eminim

  • aslında tabloyu değiştirmeden varolan bir tabloyu genişletmek istiyorum. Belki bir üçüncü taraf satıcı tarafından sağlanan ve sadece aynı anahtarı paylaşır ikinci bir tablo alarak ayrılmış uzantılarını tutmak istiyorum edildi.
  • belki sık sık erişilen tabloda sabit genişlikli sütunlar ve olmayan değişken olanları vardır. Bu durumda, her şey için bir ikincil tablo ile, sık sık şeyler için sabit bir satır uzunluğunda bir tablo zorunda olduğu için verimlilik artışları olabilir.

Bir veritabanı normalleştirme zaman da, söylemek 3rd Normal Form (3NF) Eğer anahtarı "hakkında" gerçekten değil ve ayrı bir tablo çıkardı gereken sütunlar var bulabilirsiniz.

Bilgi parçası isteğe bağlı olarak mümkün olduğunda bir kullanımıdır. Bu şekilde büyük bir tablodaki null alanlar bir grup var gerekmez, ancak zorunlu masa ve isteğe bağlı bir tabloya mantıksal ayırabilirsiniz.

Bazı veriler farklı tablolar ile paylaşıldığında, diğer kullanılmasıdır. Örneğin en Eğer bilgisayar parçaları satmak bir site var diyelim. Tüm bileşenler, örneğin içine paylaştıkları ayrıntıları koyabilirsiniz. "Parçalar" masa, ama sadece bir-bir ilişkisi parça tabloyu kullanmak istiyorsunuz vb "anakartlar", "CPU", in özelliklerini koydu.

En yaygın nedeni ilişkisi olmayan zorunlu olabilir olmasıdır. yani her baz varlık için geçerli nitelikleri ama sadece bir alt kümesine için geçerli bazı özellikleri bir dizi var.

Bunu yapmak için başka bir geçerli nedenin erişim haklarını denetlemek için - Eğer uygulama boyunca kullanılan müşterilerinin bir tablo olabilir, ve her müşteri bir şifre ve kredi kartı ha rağmen, görünürlük / güncelleme yetkilerini kısıtlamak isteyebilirsiniz.

Ignacio Vazquez-Abrams cevaba Marga Keuvelaar ait açıklama yanlış. Sen iyi DML / DDL ama her durumda değil kullanarak etkisini hafifletmek mümkün olabilir. Her zaman dikkate alınması gereken - Ancak performans faydaları karşı veri-model saydamlığı ticaret.

C.

Veritabanı motoru alanlarından sadece bir alt kümesi okunan olsa bile, onlardan veri çekmek amacıyla belleğe tüm satırları yüklemek zorunda kalabilirsiniz. Satır başına daha az alanlar az disk girişler demektir sayfa başına daha fazla satır anlamına gelir.

OO size miras var. Yani üst nesnenin veri ve çocuklar için özel olan alanları içeren diğer tablolar içeren bir tablo olabilir.

Biz too many fields (! 96 alanlar) ile masamıza birini uzatmak için gerektiğinde biz "1-1 ilişki" kullanmış; bu yüzden, biz başka bir tablo oluşturulur ve bunun içinde her yeni alan koyacağız.

Neyse, ben gibi bir yaklaşımdır:

Table_Base:
    ID
    MANDATORY_FIELD
Table_Option:
    ID
    OPTIONAL_FIELD

Zaten söylenmiştir ne ek olarak,

Bazı sütunlar diğerlerinden daha farklı "güvenlik boşluğu" gereksinimleri olabilir. Örneğin bir çalışanın adını onun maaş daha "biraz daha kamusal" olabilir. Şimdi, sütun düzey güvenlik genellikle DBMS tarafından zorlanmaz, ancak tablo-düzey güvenlik genellikle.

Yani ayrı bir tabloda maaş singling tarafından, sadece DBMS güvenlik olanakları kullanarak kullanıcının güvenlik gereksinimlerini uygulamak için kendinize olasılığını satın.