PHP、MySQL、Jqueryテンプレート、JSONを使用して、非常に簡単なToDoリストアプリケーションを作成しようとしています。しかし、私のスキーマはJSONで物事を複雑にしているようです。
それを行う最良の方法は何ですか？
または
回答:
しばらく前に聞いたジョークがあります：
Q BASICコーダーはどのように10にカウントされますか？1,2,3,4,5,6,7,8,9,10
Q Cコーダーはどのように10にカウントされますか？0,1,2,3,4,5,6,7,8,9
Q DBAはどのように10にカウントされますか？0,1、多くの
このジョークの背後にある真実は、データベース構造（列またはテーブル）に同じものが2つ（またはそれ以上）あると、間違ったことになります。
次のようなスキーマ：
+----------+
| id |
| name |
| phone1 |
| phone2 |
| |
+----------+
誰かがそれを持っている場合、どこに3番目の電話番号を置くので間違っていますか？
テーブル自体にも同じことが当てはまります。また、実行時にスキーマを変更するのは悪いことであり、「各リストの新しいテーブル」はそれを暗示しているようです。（関連：MVC4：実行時にモデルを作成する方法？）
したがって、解決策は、2つのテーブルで構成されるToDoリストを作成することです。リストとアイテムの2つがあります。
それで、これを反映するテーブル構造を作ってみましょう。
+----------+ +-------------+
| List | | Task |
+----------+ +-------------+
| id (pk) <---+ | id (pk) |
| name | +---+ listid (fk) |
| | | desc |
| | | |
+----------+ +-------------+
リストにはid（リストの主キー）と名前があります。タスクには、id（主キー）、listid（外部キー）、およびタスクの説明があります。外部キーは、別のテーブルの主キーに関連しています。
これは、ソフトウェアおよびそれをサポートするためのテーブル構造のさまざまな要件のすべての可能性を網羅し始めていないことを指摘します。完了、期日、繰り返しなど...これらはすべて、テーブルを設計するときに考慮する必要がある追加の構造です。つまり、テーブル構造が適切に正規化されている（または正規化されていないために行ったトレードオフを実現する）構造でない場合、後で多くの頭痛の種になります。
さて、これはリレーショナルデータベースとしてこれを書くことに関連しています。しかし、そこにあるデータベースのタイプはそれだけではありません。あなたはリストがあることを考慮すれば、文書ドキュメントでは、NoSQLのデータベースをスタイルも間違っていないアプローチを提供することがあります。
あまり深く掘り下げるつもりはありませんが、ソファにあるtodoリストのチュートリアルはたくさんあります。検索を思いついたものの1つは、CouchDBの単純なタスクリストアプリケーションです。もう1つはcouchdb wikiに表示されます：To Doリストのスキーマの提案。
ソファに適したアプローチでは、各リストはデータベースに保存されたJSONドキュメントです。リストをJSONオブジェクトに入れて、データベースに入れるだけです。そして、データベースから読み取ります。
JSONは次のようになります。
[
{"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でjsonファイルを使用して買い物リストを作成することから）。
またはそれに近づく何か。ソファがドキュメントの一部として保持している他の記録がいくつかあります。
事は、そのないアプローチには間違った方法および文書データベースにおけるToDoリストは完全にあなたがのために以下のコンセプトのオーバーヘッドでやろうとしているものに適していること、であるどのようにそれを行います。
オプション2は、従来のマスター/詳細設定です。それはおそらくあなたがここで欲しいものです。リストIDをitemsテーブルに入れ、それに参加します。スキーマはJSONに影響を与えません。クエリは次のようになります。
select lists.name as list_name, items.name as item_name
from items
join lists on (lists.id = items.list_id)
UI表現またはデータのUIへの送信を、データの保存方法に直接結び付けようとはしません。2つを別々に保ち、いくつかのミドルウェアロジックを使用して2つを結合することにより、重要な方法で他に影響を与えることなく、一方を簡単に変更できます。
データストレージの観点からは、一般的な正規化されたデータパターンに従うオプション2を使用します。このパターンでは、共通部分が独自のテーブルにファクタリングされ、繰り返しを避けてデータベースの膨張を最小限に抑えます。
ビューの観点からは、データベースクエリを使用して適切なデータを結果セットに結合し、その結果を反復処理して、UIのニーズに適したjson応答を生成するだけです。おそらくやりたいことは、データをJSONにフィードして、UIのニーズに可能な限り一致させ、多くの場合、Webページでの追加のスクリプトロジックの必要性を排除することです。