Ben başka bir tablo yapmak veya sadece diziler kullanmalı mıyım?

3 Cevap php

Mevcut durum konular 3 ana kategoriye göre sıralanır olmasıdır. Orada sadece 3 kategoride daha fazla eklemek için potansiyel ancak yüksek ups bir konuya sadece 1 kategori daha fazla eklemek için yeteneği uygulamak istiyoruz.

Benim orijinal db tasarım konu bilgi tabloda bir yabancı anahtar olarak KategoriNo sahiptir. Hangi muhtemelen baştan kötü bir fikir olduğunu ama onlar sadece daha az sorgular için izin verecek 3 kategorisi olan ve bunu bu şekilde yapıyor kuruldu düşündüm.

So from what I can see I have two options now: 1) Input the categoryID as a comma separated string that I parse on the php end. 2) Restructure the DB and pull out the categoryID into its own table of categoryID and topicID.

Herkesin bu ne düşündüğünü merak ediyorum. Benim ilk içgüdüsü veritabanını yeniden yapılandırılması oldu. Ama bunu düşünmek ilk seçenek uygulamak için en kolay ve çevresinde db değiştirerek varolan bir şey kırmak için en az muhtemeldir. Bu da ancak-normalleşmesini de ve tutarsız veri olasılığını açmak yol açabilir.

Ben de-normalize kadar uzun performans karşılığında tutarsız verilere sahip riskini kabul olarak gayet okudum. Sizce ben bu riski için performans çok kazanacak? Ben bu durumda ne yapması gerektiğini herhangi bir giriş mutluluk duyacağız.

Thanks for the help,
Levi

3 Cevap

Kimlikleri virgülle ayrılmış listesi iğrençtir ile ('oyları' tablosundan o her zaman hesaplama aksine SO soru ile birlikte soru üzerinde oy sayısını tutuyor hangi bir iyi bir örnek) denormalizasyon karıştırmayın.

Uygun bir çok-çok ilişki modeli; (ve olacak) virgülle ayrılmış bir yaklaşım ile yanlış gidebilir sadece çok şey var. Birkaç isim:

  1. Hiçbir bilgi tutarlılığı.
  2. Sonraki imkansız katılır kullanmak.
  3. Yeterince endeksi imkansız; non-ölçeklenebilir.

Eğer konu ait olduğu kategoriler bulmak için categoryID-topicID çiftleri, dediğim gibi en iyi seçenek, bir veritabanına sahip olacaktır.

Çok fazla kaynak yoğun ... bunu categoryID dizeleri patlayan tarafından başka bir yol yapmak OLABİLECEK, ama belli bir kategoride herhangi bir konu için arama yaptığınızda, her alan ile çalıştırın ve üzerinde bir LIKE çalıştırmak zorunda olacak .

DB yeniden yapılandırılması için zaman ayırın ve çok daha iyi bir sonuç ile bitireceğiz.

Eğer, ürüne ile DBMS şey yapmak not liste şeklinde saklayabilirsiniz yapmak gerekiyorsa. Bu tablolar büyük olsun gibi sorgular bir köpek gibi çalışmasını sağlamak olacaktır. Sen sadece bir birim olarak listesini tedavi için gidiyoruz eğer Tabii ki, onları bu şekilde saklamak tamam.

Ama daha iyi bir birim olduğunu söyleyerek ve sonra başka bir yerde onları ayrı spiltting, her bir birim, ve hiçbir hile gibi listesini tedavi için gidiyoruz emin olurdum - daha iyi izin DBMS bunu senin için.

Sen always 3NF ilk o zaman, hız için denormalize, performans sorunları varsa, sadece ve sadece var olmalıdır.

Eğer söz bahsediyoruz bu alanlar bir birim olarak tedavi edilecek sıralama değildir. Siz listelerde tek tek elemanlara şeyler yapmak gerekir, bu yüzden başka bir tablo içine kırık olmalıdır.