私はプロジェクトに取り組んでいます。主に学習目的ですが、基本を理解した後に言語を学ぶには、複雑なプロジェクトを実際に試すことが最善の方法であることがわかりました。データベース設計は強みではありません。私はそれについて読み始めましたが、初期の段階であり、まだ学習中です。
これが私のアルファ スキーマです。私は、考えられることをすべて書き留めて、問題が発生するかどうかを確認しようとしているところです。 http://diagrams.seaquail.net/Diagram.aspx?ID=10094#
フィードバックが欲しい私の懸念のいくつか：
たとえば、エリアなどのコア属性に注意してください。簡単にするために、エリアがキッチン、ベッドルーム、庭、バスルーム、リビングルームであるとしましょう。ホームページ、連絡先ページ、about_us、スプラッシュ画面など、別の顧客の場合。2 エリアでも 100 エリアでもかまいませんが、制限する必要はありません。
デフォルト用に個別のテーブルを作成しましたが、それぞれがバグにリンクされています。後で、カスタム フィールドの問題に行き着きました。たとえば、バグがどのテーマに適用されるかを誰かがマークしたい場合、それはありません。おそらく他に 100 のものが存在するので、属性のコア セットとカスタム フィールドに固執したかったのです。人々に柔軟性を与えます。
ただし、カスタム フィールドに到達したときに、問題があることがわかっていたので、カスタム フィールドごとにテーブルを作成することはできなかったので、代わりに 2 つのテーブルを使用しました。カスタム フィールドと custom_field_values。アイデアは、デフォルトを含むすべてのフィールドがこのテーブルに保存され、それぞれがこのようなものを持つ値テーブルにリンクされるということです
custom_fields table
id project_id name
01 1 area(default)
12 2 rooms(custom)
13 4 website(custom)
custom_field_values table
id area project_id sort_number
667 area1 1 1
668 area2 1 2
669 area3 1 3
670 area4 1 4
671 bedroom 2 1
672 bathroom 2 2
673 garden 2 3
674 livingroom 2 4
675 homepage 4 1
676 about_us 4 2
677 contact 4 3
678 splash page 4 4
これは、このような動的フィールドを処理する効率的な方法のように見えますか、それとも他の代替手段はありますか?
デフォルトはハードコーディングされるため、それらを使用するか、独自のものに置き換えるか、別のテーブルを作成して、プロジェクトにリンクされるデフォルトの名前をユーザーが編集できるようにすることができます。フィードバックは大歓迎です。スキームの問題について非常に明白なことがあれば、遠慮なく批評してください。