基本情報のスキーマ設計にはどのようなものが最適ですか？

Question

同じプロパティを含むアプリケーションでは、少なくとも50個のオブジェクト（たとえば、city、country、color、personelType、organizationTypeなど）があります。これらのプロパティは含まれていますID、Topic、Code、同じプロパティが含まれ、これらのオブジェクトのisActive

• 、我々はBaseInfoとBaseHeaderとして知られている2つのオブジェクトを作成します。このオブジェクトの設計テーブルのための
• 、我々は1つのBase-Headerとして知られているテーブルとBase-Infoとして知られている他のテーブルを作成します。これらのテーブルの関係は次のとおりです。https://pasteboard.co/GQeV4Rl.png

開発者は、必要に応じてBase-Headerに新しいレコードを追加します。例えば、開発者はBase-Headerを見ると、それはcity用テーブル内のレコードがないならば、都市オブジェクトごとに1件のレコードを追加：insert into Base-Header (id, topic) values (1, 'city');や色のため：insert into Base-Header (id, topic) values (2, 'color');を。この後、すべての開発者がBase-Infoに都市レコードでheaderIdフィールドの値が1、市内の取得データのためのアプリケーションにこのIDをハードコーディングすることができますことを知られています。アプリケーションで同じステータスのオブジェクト。

この計画では、同じプロパティを持つcity,colorなどのテーブルとオブジェクトを作成する必要はありません。市内のレコードを必要とする他のテーブルのすべての外部キーは、彼らはBase-Infoテーブルと添付されています。このテーブルとオブジェクトのデザインは正しいですか？

• このスキーマ[https://pasteboard.co/GQnqaT5.png]があり、これを[https://pasteboard.co/GQnqiCE.png]に変更したとします。この作業では、同じ小道具を持つすべてのオブジェクトとテーブルを削除します。注意。クエリは変更されず、joinまたはwhere句は追加されません。外部キーだけがBase_Infoに変わります。これは複雑ですか？

おかげでたくさん...

Answer 1

私はあなたの実際の問題を取得できませんでした。しかし、私はあなたに上記の問題のためのデータベースを設計する一つのアイデアを提案することができます。頻繁に変化しないオブジェクト（都市、国、色、pesonnelTypeなど）のリストを列挙できれば、上記のすべてのオブジェクトをIDとともに単一のテーブルに格納できます。ベース情報テーブルに列を追加して、それぞれのオブジェクトのIDを格納します。したがって、最新のベース情報テーブルには、1つの特別な列object-idがあります。私はあなたの問題がこのように解決されると思います。

Answer 2

最初にビジネス要件を分析する必要があります。一度すべてが置かれると便利になるでしょう。あなたの声明で気づいたように、ビジネスアナリストは見直していないようです。これをBAの観点から参照する必要があります。一度コンパイルして要約すると、データウェアハウスを行う技術的観点から明らかになります。

Answer 3

ここでEAVタイプのアプローチをお試しいただいているようです。 RDBMSには適していません。設計上の問題ではなく、パフォーマンス上の問題ではなく、ユーザビリティ上の問題ではありません。

BaseHeaderの唯一の目的が実体に型を与えることであれば、それは本当に必要ではありません。 Lawakushが示しているように、別のテーブルの代わりにenumフィールドを使用することもできます（データベースがサポートしている場合はそれをエミュレートできます）。

EAVモデルをお使いになる場合は、警告されています。 「何か」をモデル化することは素晴らしいと思われるかもしれませんが、データベースの適切な保護手段がないためにデータが壊れてしまい、膨大な量のゴミで終わる可能性があります。外部キーは、 EAVモデル。