Yapılacaklar listesi için veritabanı şeması

PHP, MySQL, Jquery templating ve JSON ile çok basit bir yapılacaklar listesi uygulaması yapmaya çalışıyorum ... Ancak, benim şem JSON şeyleri karmaşık gibi görünüyor.

Bunu yapmanın en iyi yolu nedir?

1. Her liste için öğeleri içeren yeni bir tablo.

veya

2. listeler için bir tablo ve bir şekilde birleştirilen öğeler için bir tablo mu? Çünkü bunu denedim ve bunu yapmanın doğru yolu değil mi? Örnek http://jsfiddle.net/Lto3xuhe/

Bir süre önce duyduğum bir şaka var:

S: BASIC kodlayıcı 10'a nasıl eşittir?
bir 1,2,3,4,5,6,7,8,9,10

S Bir C kodlayıcısı 10'a nasıl eşittir?
A 0,1,2,3,4,5,6,7,8,9

S Bir DBA 10'a nasıl karşılık gelir?
A 0,1, çok

Bu şakanın ardındaki gerçek şu ki , bir veritabanı yapısında (sütunlar veya tablolar) aynı şeyin iki (veya daha fazlasının) olduğunda, yanlış yapıyorsunuz.

Şuna benzeyen bir şema:

+----------+
| id       |
| name     |
| phone1   |
| phone2   |
|          |
+----------+

Yanlış, çünkü eğer birisi varsa üçüncü bir telefon numarasını nereye koyacaksınız?

Aynısı tabloların kendileri için de geçerlidir. Ayrıca çalışma zamanında şemayı değiştirmek için kötü bir şey, "her liste için yeni tablo" ima gibi görünüyor. (İlgili: MVC4: Çalışma zamanında model nasıl oluşturulur? )

Ve böylece çözüm, iki tablodan oluşan bir yapılacaklar listesi oluşturmaktır. Sahip olduğunuz iki şey var - listeler ve öğeler.

Yani, bunu yansıtan bir tablo yapısı yapalım:

+----------+       +-------------+
| List     |       | Task        |
+----------+       +-------------+
| id (pk)  <---+   | id (pk)     |
| name     |   +---+ listid (fk) |
|          |       | desc        |
|          |       |             |
+----------+       +-------------+

Listenin bir kimliği (listenin birincil anahtarı) ve bir adı vardır. Görevin bir kimliği (birincil anahtar) bir liste kimliği (yabancı anahtar) ve görevin açıklaması vardır. Yabancı anahtar başka bir tablonun birincil anahtarıyla ilgilidir.

Bunun, yazılım ve tablo yapısını desteklemek için çeşitli gereksinimlerdeki tüm olasılıkları kapsamadığını belirteceğim. Tamamlandı, bitiş tarihi, tekrarlama, vb ... bunların hepsi, tablo tasarlanırken dikkate alınması gereken ek yapılardır. Bununla birlikte, tablo yapısı uygun şekilde normalleştirilmiş bir yapı değilse (veya normalleşmediği için yaptığınız takasları gerçekleştirirse), daha sonra birçok baş ağrınız olacaktır.

Şimdi, tüm bunlar bunu ilişkisel bir veritabanı olarak yazmakla ilgilidir. Ama bu tek veritabanı türü değil. Bir listeyi belge olarak değerlendirirseniz , nosql veri tabanları içeren belge de yanlış olmayan bir yaklaşım sunabilir.

Çok fazla araştırmayacağım, ancak kanepede yapılacaklar listesi için çok sayıda öğretici var. Bir arama ile ortaya çıkan böyle bir CouchDB basit bir Görev listesi uygulamasıdır . Başka bir couchdb wiki'sinde gösterilir: Yapılacaklar Listesi İçin Önerilen Şema .

Kanepe için uygun yaklaşımda, her liste veritabanında saklanan bir JSON belgesidir. Listeyi sadece bir JSON nesnesine ve veritabanına koyarsınız. Ve sonra veritabanından okudunuz.

JSON şöyle görünebilir:

[
 {"task":"get milk","who":"Scott","dueDate":"2013-05-19","done":false},
 {"task":"get broccoli","who":"Elisabeth","dueDate":"2013-05-21","done":false},
 {"task":"get garlic","who":"Trish","dueDate":"2013-05-30","done":false},
 {"task":"get eggs","who":"Josh","dueDate":"2013-05-15","done":true}
]

( Stack Overflow'da json dosyası içeren bir alışveriş listesi oluşturmaktan ).

Ya da ona yaklaşan bir şey. Kanepenin belgenin bir parçası olarak saklandığı başka bir kayıt daha var.

Mesele şu ki, yanlış bir yaklaşım yolu değil ve bir belge veritabanındaki yapılacaklar listesi, bunu nasıl yapacağınız için daha az konsept yükü ile yapmaya çalıştığınız şey için mükemmel bir şekilde uygun olabilir .

Seçenek 2, geleneksel bir ana / ayrıntı kurulumudur. Muhtemelen burada istediğiniz şey budur. Liste kimliğini öğeler tablosuna koyun ve buna katılın. Şema JSON'u etkilememelidir. Sorgunuz şuna benzeyebilir:

select lists.name as list_name, items.name as item_name 
from items 
join lists on (lists.id = items.list_id)

UI temsilini veya veri iletimini doğrudan veriyi depolamayı düşündüğünüz UI'ye bağlamaya çalışmam. İkisini ayrı tutarak ve evlenmek için bazı ara katman yazılımı mantığı kullanarak, ikisini de kritik bir şekilde etkilemeden her iki tarafı da kolayca değiştirmenize izin verir.

Veri depolama perspektifinden bakıldığında, ortak parçaların tekrardan kaçınmak ve veritabanı şişkinliğini en aza indirmek için ortak tabloların kendi tablolarına katlandığı tipik normalleştirilmiş veri desenini izleyen seçenek 2'yi kullanmanız muhtemeldir.

Bir bakış açısından, ilgili verileri bir sonuç kümesine birleştirmek için bir veritabanı sorgusu kullanmanız ve daha sonra bu sonucu yinelemeniz ve UI gereksinimleriniz için geçerli bir json yanıtı oluşturmanız gerekir. Yapmak istediğiniz şey, verileri JSON'a beslemektir, böylece kullanıcı arayüzünüzün gereksinimlerine en iyi şekilde uyar ve genellikle web sayfalarınızda ek komut dosyası mantığı ihtiyacını ortadan kaldırır.