web-dev-qa-db-ja.com

値と追加の列を保持するためのデータベース設計

同僚と私はデータベース設計を思い付くのに苦労しており、今のところEAVに近づかないように最善を尽くしています。

マシンの構成データを格納するPreparationというエンティティがあります。マシンごとに2種類のプロセスがあります。これらをprocess1とprocess2と呼びましょう。マシンは、1つのプロセスしか持つことができません。どちらのプロセスも多くの属性を共有しているため、1つのテーブルを設定することは論理的であるように思われました。

ただし、process2には多くの追加データがあり、それらのサブカテゴリに固有のprocess2a、processes2bでサブカテゴリ化されています（process1には次の1つの追加属性しかありません今）。そのため、1つのテーブルのプロセスに固有ではない列にnullが含まれます。

プロセスごとにテーブルを分割することも別のオプションでした。ただし、データの変更を保持する必要があり、テーブルを分割すると作業量が増えます（ほとんどすべてのトランザクションは、履歴テーブルにタイムスタンプが付いたINSERTSになり、その後にライブテーブルでUPDATEが続きますレコードを更新している場合）。たとえば、マシンがprocess1からprocess2に変更された場合、レコードはprocess1から履歴テーブルに挿入され、process1から削除されてからに挿入される必要があります。 process2。 SQL Serverの標準エディションを使用しているため、変更のログ記録に役立つCDCはありません。

私はこれらのかなりの関係を維持しようとしていますが、期待されるNULLを含む1つのテーブルを作成するのは嫌です（NULLの割合が高い場合はSPARSE列を作成する可能性がありますか？）。

私は誰かがこの種の状況を経験したことを望んでいます。ありがとうございました。

sql-serverdatabase-designeav
1
jmzagorski

さまざまなプロセスをサブタイプとして扱います。次に、エンティティprocess_baseがあります。これには、プロセス固有の属性のすべての共通属性process1、process2、process2aなどが含まれます。

これらをそれぞれテーブルとして実装します。それらをすべて組み合わせたビューは、使用法を簡素化する可能性があります

create view process_all as
select <whatever>
from process_base
inner join process1 <etc>

union all

select <whatever>
from process_base
inner join process2 <etc>
...

このようにして、NULL列を最小限に抑えますが（それが望ましい場合）、「プロセス」の統一性を単一のアイデアとして維持します。

1
Michael Green

次のいずれかを実行する必要があるフィールドはどれですか？

  • 並べ替え
  • フィルタリング
  • カウント
  • グループ化
  • 型チェック

表示するためだけに保存​​したいフィールドがある場合は、それらを独自の列に配置する必要はありません。それらをJSON、XML、またはその他のシリアル化された形式で保存できます。

ただし、フィールドで上記を実行する必要がある場合は、ほぼ確実に、実際のデータベース列が必要になります。そして、実際のデータベース列とは、EAVやLOBではないことを意味します。

大変な作業のように思われる場合は、Hibernate（継承あり）を使用してデータベーススキーマを生成することを検討してください。また、HibernateEnversを使用して変更のキャプチャを処理します。

1
Neil McGuigan