4

私は、後でそれぞれのレポートを生成するために使用されるビジネスロジック用に30の異なるフィールドを格納する必要があるプロジェクトを実行しています

30の異なるフィールドは一度に書き込まれません。ビジネスロジックには非常に多くのトランザクションがあり、次のようになります。

Transaction 1, update field 1-4
Transaction 2, update field 3,5,9
Transaction 3, update field 8,12, 20-30
...
...

注意：各トランザクション（すべて1つのビジネスロジックに属する）は、特定の順序ではなく、任意の数のフィールドを更新します。

私のデータベース設計は何が最善であるか疑問に思っています。

  1. postgresデータベースに30個の異なるフィールドを表す30個の列があります。

  2. xmlまたはjsonの形式で30のファイルストアを用意し、postgresの1列だけに保存​​します。

1または2どちらが良いですか？

1>を選択した場合：

プログラミングの観点からは簡単です。このようにして、xml / json全体を読み取り、いくつかのフィールドだけを更新してからデータベースに書き戻す必要がないため、トランザクションごとに必要ないくつかの列しか更新できません。

2>を選択した場合：

blob列内にあるのはxmlのみであるため、テーブルを他の目的で一般的に再利用できる可能性があります。しかし、xmlを格納するblob列があるという理由だけで、テーブルジェネリックを使用してビジネスロジックにまったく関係のないものを格納するのは間違っていますか？これにより、いくつかの新しいテーブルを作成する手間を省くことができます。しかし、テーブルを再利用するというこの種の一般的な考え方は、RDBMSでは間違っていますか？

また、2>を選択することで、特定のフィールドの変更/フィールドの追加などの潜在的な変更を処理できるように見えますか？少なくとも、データベーステーブルを変更する必要はないようです。ただし、変更を内部で処理するには、c ++とc＃のコードを変更する必要があります。これが利点かどうかはわかりません。

私はデータベース設計の経験が浅いので、どちらを選ぶか決めることができません。どんな入力でも大歓迎です。

NB私はおそらく今のところそれらの30の列でインデックスを作成したり検索したりする必要がない可能性が高いです。主キーは、2>を選択すると追加の列に作成されます。しかし、後でそれらの列/フィールドのいずれかに基づいて検索を行う必要があるかどうかはわかりません。

基本的に、私のすべてのフィールドは要件ドキュメントから事前定義されており、一般的に単純なフィールドが好きです。

field1: value(max len 10)
field2: value(max len 20)
...
field20: value((max len 2)

ネストフィールドはありません。これらのフィールドごとに20列を作成する価値があります（日付/時刻のような文字列、文字列、整数など）。

2>異なるビジネスロジックを共有テーブルに配置することは、悪い設計アイデアですか？同じ構造を共有しているために共有テーブルに配置されるだけの場合はどうでしょうか。たとえば、それらはすべて、日時列、主キー、および内部に異なるビジネスロジックを持つxml列を持っていますか？このようにして、新しいテーブルを作成するための作業を安全に行うことができます...この節約作業は実行する価値がありますか？

4

3 に答える 3

4

XML / JSONフィールドは、常に個別のフィールドとしてリレーショナルデータベースに保存してください。そうすることで、データベースを正規化して、データベースがクエリやインデックスなどで処理できるようになります。また、他の開発者がXML/JSONフィールドを解読する手間を省くことができます。

XML / JSONからフィールドを抽出し、フィールドを追加する必要がある場合はそれを維持する方が前もって作業が必要になりますが、1つまたは複数のクラスを作成すると、ハードルがなくなり、それ以上のことが可能になります。不可解なblobフィールドを探します。

于 2012-11-08T17:28:01.177 に答える
3

一般に、JSONまたはXMLドキュメントを分割して、個別の列として保存することをお勧めします。これにより、検証とチェックのために列に制約を設定したり、列にインデックスを付けたり、各フィールドに適切なデータ型を使用したり、通常はデータベースの機能を使用したりすることができます。

これを行うためのツールは多数あるため、オブジェクトへのマッピングやオブジェクトからのマッピングは一般的にそれほど難しくありません。たとえば、JavaはJAXBとJPAを提供します。

それを分割するときの主な時期は、JSONまたはXMLドキュメントのフィールドが何であるか、またはそれらのフィールドがいくつあるかを事前に知らない場合です。この場合、実際には2つの選択肢しかありません。EAVのようなデータモデルを使用するか、ドキュメントをデータベースフィールドとして直接保存するかです。

この場合（そしてこの場合のみ）、ドキュメントをデータベースに直接保存することを検討します。PostgreSQLのSQL/XMLサポートは、式に式インデックスを作成できxpath、一部の検証にトリガーを使用できることを意味します。

これは良いオプションではありません。EAVは通常さらに悪いオプションであるというだけです。

ドキュメントが「フラット」である場合（つまり、ネストのない単一レベルのキーと値）は、データ型がはるかに強力であるためhstore、代わりにドキュメントを保存することを検討してください。hstore

于 2012-11-09T01:27:21.717 に答える
2

（1）は、正当な理由から、より標準的です。データベースが1つのものの検索やインデックス作成などの面倒な作業を実行できるようにします。

于 2012-11-08T17:19:24.107 に答える