Listeleri ilişkisel bir veritabanında kullanmak hiç sorun değil mi?

Proje konseptine uygun bir veritabanı tasarlamaya çalışıyorum ve çok tartışılan bir konu gibi göründüm. Birkaç makale okudum ve bazı Stack Overflow cevapları bir alanda bir ID listesi veya benzeri bir şey saklamanın asla (veya neredeyse hiç) tamam olmadığını belirtir - tüm veriler ilişkisel olmalıdır, vb.

Karşılaştığım sorun olsa da, bir görevli görevli yapmaya çalışıyorum. İnsanlar görevler yaratacak, onları birden fazla kişiye atayacak ve veritabanına kaydedecektir.

Tabii ki, bu görevleri "Kişi" bölümünde ayrı ayrı kaydedersem, onlarca kukla "TaskID" sütununa sahip olmalıyım ve bunları mikro-yönetmem gerekecek, çünkü bir kişiye atanmış 0 ila 100 görev olabilir.

Sonra tekrar, görevleri "Görevler" tablosuna kaydedersem, onlarca sahte "PersonID" sütununa sahip olmalıyım ve bunları daha önce olduğu gibi mikro yönetmeliyim.

Böyle bir problem için, bir form ya da diğerini alarak bir kimlik listesini kaydetmem uygun mudur, yoksa bunun ilkeleri ihlal etmeden elde edilebilecek başka bir yol düşünmüyor muyum?

Araştırmanız gereken anahtar kelime ve anahtar kavram veritabanı normalleşmesidir .

Yapacağınız şey, kişiye veya görev tablolarına atamalar hakkında bilgi eklemek yerine, ilgili atama bilgileriyle ilgili ilişkilerle birlikte yeni bir tablo eklemenizdir.

Örneğin, aşağıdaki tablolara sahipsiniz:

Kişiler:

+ ---- + ----------- +
| Kimlik | İsim |
+ ==== + =========== +
| 1 | Alfred |
| 2 | Jebediah |
| 3 | Jacob |
| 4 | Ezekiel |
+ ---- + ----------- +

Görevler:

+ ---- + -------------------- +
| Kimlik | İsim |
+ ==== + ==================== +
| 1 | Tavukları Besle |
| 2 | Pulluk |
| 3 | Sağım İnekleri |
| 4 | Bir ahır kaldırın |
+ ---- + -------------------- +

Daha sonra Atamalar ile üçüncü bir tablo oluşturun. Bu tablo, insanlar ve görevler arasındaki ilişkiyi modelleyecektir:

+ ---- + ----------- + --------- +
| Kimlik | PersonId | Görev Kimliği |
+ ==== + =========== + ========= +
| 1 | 1 | 3 |
| 2 | 3 | 2 |
| 3 | 2 | 1 |
| 4 | 1 | 4 |
+ ---- + ----------- + --------- +

Daha sonra, bir Yabancı Anahtar kısıtlamasına sahip olacağız, böylece veritabanı, Kişisel Kimlik ve Görev Kimliği'nin bu yabancı öğeler için geçerli kimlikler olması gerektiğini zorunlu kılar. İlk satır için görebiliriz PersonId is 1böylece, Alfred , atanan TaskId 3, Sağım inekler .

Burada görmeniz gereken şey, görev başına ya da kişi başına istediğiniz kadar az ya da daha fazla ödev verebileceğinizdir. Bu örnekte, Ezekiel'e herhangi bir görev verilmez ve Alfred , 2'ye SELECT PersonId from Assignments WHERE TaskId=<whatever>;atanır. Şunları yapabilirsiniz WHEREPersonId o kişiye atanmış tüm görevleri bulmak için.

Kimlikleri Adlar ve görevlerle değiştiren sorguları iade etmek istiyorsanız, tablolara nasıl katılacağını öğrenirsiniz.

Burada iki soru soruyorsun.

İlk önce, bir sütunda serileştirilmiş listeleri saklamak için uygun olup olmadığını sorun. Evet bu iyi. Projeniz bunun için çağırırsa. Örnek olarak, her bir içeriği ayrı ayrı takip etmek istemediğiniz bir katalog sayfası için ürün bileşenleri olabilir.

Maalesef ikinci sorunuz daha ilişkisel bir yaklaşım tercih etmeniz gereken bir senaryoyu açıklar. 3 masaya ihtiyacınız olacak. Biri halk için, biri görevler için, diğeri ise hangi görevin hangi kişilere atandığını listeler. Bu sonuncusu dikey olacak, kişi / görev kombinasyonuna göre bir satır, birincil anahtarınız için sütunlar, görev kimliği ve kişi kimliği.

Ne tarif ettiğin arasında durumunda, ilişki bir "Birçok birçok" olarak bilinir Personve Task. Genellikle, bazen "link" veya "çapraz referans" tablosu olarak adlandırılan üçüncü bir tablo kullanılarak uygulanır. Örneğin:

create table person (
    person_id integer primary key,
    ...
);

create table task (
    task_id integer primary key,
    ...
);

create table person_task_xref (
    person_id integer not null,
    task_id integer not null,
    primary key (person_id, task_id),
    foreign key (person_id) references person (person_id),
    foreign key (task_id) references task (task_id)
);

... bir alanda bir kimlik veya benzeri listesini saklamak asla (veya neredeyse hiç) tamam değildir

Eğer sadece zaman olabilir o alan olduğunda tek bir alandaki birden fazla veri öğesi depolamak olduğunu sadece şimdiye kadar tek bir varlık olarak da kullanılır; asla bu küçük elemanların yapılmış olarak değerlendirmiştir. Bir örnek, bir BLOB alanında depolanan bir görüntü olabilir. Çok fazla ve çok sayıda küçük elemandan (bayt) oluşur, ancak bunlar veritabanında hiçbir şey ifade etmez ve yalnızca birlikte kullanılabilir (ve bir Son Kullanıcıya hoş görünürler).

Bir "liste", tanımı gereği, daha küçük elemanlardan (öğeler) oluştuğundan, buradaki durum bu değildir ve verileri normalleştirmelisiniz.

... bu görevleri tek tek "Kişi" de kaydedersem, onlarca sahte "TaskID" sütununa sahip olmak zorunda kalacağım ...

Hayır . Kişi ve Görev arasında bir Kavşak Tablosunda (aka Zayıf Varlık) birkaç satır olacak. Veritabanları birçok satırla çalışmakta gerçekten iyidir; aslında birçok [tekrarlanan] sütunla çalışmakta oldukça berbatlar.

Whatsisname tarafından verilen net net bir örnek.

Bazı önceden hesaplanmış alanlarda yasal olabilir.

Sorgularınızdan bazıları pahalıysa ve veritabanı tetikleyicileri kullanılarak otomatik olarak güncellenen önceden hesaplanmış alanları seçmeye karar verirseniz, listeleri bir sütun içinde tutmak meşru olabilir.

Örneğin, kullanıcı arayüzünde, her listenin çift tıkladıktan sonra tam ayrıntıları (tam listelerle) açabileceği, ızgara görünümünü kullanarak bu listeyi göstermek istiyorsunuz:

REGISTERED USER LIST
+------------------+----------------------------------------------------+
|Name              |Top 3 most visited tags                             |
+==================+====================================================+
|Peter             |Design, Fitness, Gifts                              |
+------------------+----------------------------------------------------+
|Lucy              |Fashion, Gifts, Lifestyle                           |
+------------------+----------------------------------------------------+

Müşteri yeni makaleyi ziyaret ettiğinde veya zamanlanmış görevde tetikleyici tarafından ikinci sütunu güncel tutmaya devam edersiniz.

Böyle bir alanı arama için bile uygun hale getirebilirsiniz (normal metin olarak).

Bu gibi durumlarda, liste tutmak meşrudur. Sadece maksimum alan uzunluğunu aşma ihtimalini göz önünde bulundurmanız gerekir.

Ayrıca, Microsoft Access kullanıyorsanız, sunulan çok değerli alanlar başka bir özel kullanım durumudur. Listelerinizi otomatik olarak bir alanda yönetir.

Ancak, diğer cevaplarda gösterilen standart normalleştirilmiş forma her zaman geri dönebilirsiniz.

Özet: Normal veri tabanı formları , veri modellemenin önemli yönlerini anlamak için gerekli olan teorik modeldir. Ancak elbette normalleştirme, performansı veya verileri almanın diğer maliyetlerini hesaba katmaz. Bu teorik modelin kapsamı dışında. Ancak, liste veya diğer önceden hesaplanmış (ve kontrol edilen) kopyaları saklamak pratik uygulama için genellikle gereklidir.

Yukarıdakilerin ışığında, pratik uygulamada, mükemmel normal forma dayanan sorguyu ve 20 saniye çalışmasını mı yoksa 0.08 s süren önceden hesaplanmış değerlere dayanan eşdeğer sorguyu mu tercih edeceğiz? Hiç kimse yazılım ürününü yavaşlıkla suçlanmaktan hoşlanmaz.

İki tablo verildi; Onlara Kişi ve Görev adını vereceğiz, her biri kendi kimliğine (Kişi Kimliği, Görev Kimliği) sahip ... temel fikir, onları birbirine bağlamak için üçüncü bir tablo oluşturmaktır. Bu tabloya PersonToTask adını vereceğiz. En azından kendi kimliğine ve diğer ikisine sahip olmalıdır. Yani birisini bir göreve atamak söz konusu olduğunda; artık Person tablosunu güncellemenize gerek kalmayacak, PersonToTaskTable'a yeni bir satır eklemek yeterlidir. Ve bakım daha kolay hale gelir; bir görevi silmeye ihtiyaç duyar, TaskID'ye dayalı bir SİLME olur, Kişi tablosunu daha fazla güncellemeye gerek kalmaz

CREATE TABLE dbo.PersonToTask (
    pttID INT IDENTITY(1,1) NOT NULL,
    PersonID INT NULL,
    TaskID   INT NULL
)

CREATE PROCEDURE dbo.Task_Assigned (@PersonID INT, @TaskID INT)
AS
BEGIN
    INSERT PersonToTask (PersonID, TaskID)
    VALUES (@PersonID, @TaskID)
END

CREATE PROCEDURE dbo.Task_Deleted (@TaskID INT)
AS
BEGIN
    DELETE PersonToTask  WHERE TaskID = @TaskID
    DELETE Task          WHERE TaskID = @TaskID
END

Basit bir rapora veya bir göreve atananlara ne dersiniz?

CREATE PROCEDURE dbo.Task_CurrentAssigned (@TaskID INT)
AS
BEGIN
    SELECT PersonName
    FROM   dbo.Person
    WHERE  PersonID IN (SELECT PersonID FROM dbo.PersonToTask WHERE TaskID = @TaskID)
END

Elbette daha fazlasını yapabilirsin; TaskAssigned ve TaskCompleted için DateTime alanları eklediyseniz bir TimeReport yapılabilir. Her şey sana bağlı

İnsan tarafından okunabilen Birincil anahtarlara sahipseniz ve bir görev yapısının bir tablo yapısının dikey doğası ile uğraşmadan bir görev listesi istemeniz gerektiğini söyleyebilir. yani ilk tabloyu okumak çok daha kolay.

------------------------  
Employee Name | Task 
Jack          |  1,2,5
Jill          |  4,6,7
------------------------

------------------------  
Employee Name | Task 
Jack          |  1
Jack          |  2
Jack          |  5
Jill          |  4
Jill          |  6
Jill          |  7
------------------------

O zaman soru şu olurdu: görev listesi büyük ölçüde aşağıdaki gibi gereksinimlere bağlı olacak şekilde talep üzerine depolanmalı veya oluşturulmalı mı: listenin ne sıklıkta gerektiği, kaç veri satırının mevcut olduğu, verilerin nasıl kullanılacağı vs. .. bundan sonra kullanıcı deneyimine karşı ticaretin analiz edilmesi ve ihtiyaçların karşılanması gerekir.

Örneğin, 2 sırayı oluşturan bir sorgu çalıştırarak vs 2 sırayı hatırlamak için gereken süreyi karşılaştırarak. Uzun sürerse ve kullanıcı en güncel listeye ihtiyaç duymuyorsa (* günde 1'den az değişiklik bekliyor) o zaman saklanabilir.

Veya kullanıcı, kendisine atanmış görevlerin geçmiş kaydına ihtiyaç duyuyorsa, listenin kaydedilip kaydedilmediğini de anlamalıdır. Bu gerçekten ne yaptığınıza bağlı, asla asla deme.

Başka bir masa olması gereken şeyi alıyor, 90 derece döndürüyor ve başka bir masaya atıyorsunuz.

İtemProdcode1, itemQuantity1, itemPrice1 ... itemProdcode37, itemQuantity37, itemPrice37 öğelerinin bulunduğu bir sipariş tablosuna sahip olmak gibidir. Programlı bir şekilde ele almak garip olmaktan başka, yarın birisinin 38 şey sipariş etmek isteyeceğini garanti edebilirsiniz.

'Liste' gerçekten bir liste değilse, yani bir bütün olarak durduğu ve her bir satır öğesinin açık ve bağımsız bir varlığa atıfta bulunmadığı durumlarda, kendi yolunuzla yapacağım. Bu durumda hepsini, yeterince büyük olan bazı veri türlerinde doldurun.

Bu yüzden bir düzen bir listedir, bir malzeme listesi bir listedir (veya "yana doğru" uygulamak için daha fazla bir kabus olacak bir liste listesidir). Ancak bir not / yorum ve bir şiir değildir.

"Tamam" değilse, her Wordpress sitesinin bir satırda wp_capabilities, bir satırdaki dismissed_wp_pointers listesi ve diğerlerinin bir listesi olması oldukça kötü.

Aslında bu gibi durumlarda , neredeyse her zaman listeyi istediğiniz gibi hız için daha iyi olabilir . Ancak Wordpress'in en iyi uygulamaların mükemmel bir örneği olduğu bilinmemektedir.