タイプがわからないときにデータベースにデータを保存する最良の方法

Question

データベースには、カスタムフォームのデータフィールドを表すテーブルがあります。データフィールドは、どのような制御を表現する必要があるか、どのようなバリュータイプを取るべきかを表現しています。簡略化された私は、このテーブルに2つのエンティティを持っていると言うことができます - テキストボックスは任意の文字列を取得し、テキストボックスは番号のみを取得します。

これで、データフィールド定義を参照する別のテーブルに異なる値が保存されています。タイプが異なる場合、ここにデータ値を保存する最良の方法は何ですか？

考えられる解決策の1つは、FieldValueテーブルに、可能な値タイプごとに1つのフィールドを保持することです。今ではこれは確かに冗長ですが、少なくとも私はその正しい形で保存されている値を取得します - 後でクエリを簡素化します。

FieldValue
----------
Id
DataFieldId
IntValue
DoubleValue
BoolValue
DataValue
..

別の可能性は、すべてを文字列として保存し、クエリにこれをキャストすることです。私はnhibernateで.NETを使用していますが、少なくともここにはプロジェクションがあります。クエリでintにeg stringをキャストするために使用できるキャストがあります。

いずれにせよ、これら2つのソリューションでは、クエリを実行するときに使用するタイプを知る必要がありますが、データフィールドからそれを知っているので、それは問題になりません。

ともかく;これらのソリューションのどれも良いとは思わない。彼らは？それともより良い方法はありますか？

Answer 1

3番目の「魔法」オプションはありません。特定の状況は、どのように進みたいかを決定します。

私の経験から、アプリケーションの設定などの文字列のみのソリューションが理にかなっています。通常、そのようなデータをクエリで直接使用する必要はないので、文字列形式であることをあまり気にしません。

確かではありませんが、カスタム属性を備えたエンティティを拡張している場合のようです。この場合、複数列のアプローチを使用して、正しいタイプの列のみを入力することもできます。きれいになることはありませんが、クエリを単純化するかもしれません。

私が言ったように、それはあなたが実行する必要があるかどうか、どのようなクエリ、必要なパフォーマンスなどに依存します。

Answer 2

マルチテナントデータストレージからアイデアを引くと、 MSDNで説明されているように、「名前ペア」はアイデアを大切にします. 。どういうわけか、この記事は、指摘されている特定のセクションを除いてより有用であると思います。

実際には、これをスケーラブルなソリューションにするには、保存するデータの実際のタイプを定義するメタデータテーブルを使用して、カスタムフォームのデータの種類を定義する必要があります（bool、text、int、datetime） 。また、入力検証などに関してはこれが支援できる可能性があるため、.NETタイプを保存することも検討できます。あなたのカスタムフォーム。このアプローチを使用して、保存されたメタデータに基づいてカスタムフォームを構築します。

私はこのアプローチを正常に使用しましたが、うまく機能します。追加として、メタデータテーブルを使用して、カスタムフィールドの期待値がユーザーが提供されるか（例：名前、生年月日）か、ドロップダウンリストの事前定義されたシステム値（Citye、国のリストに定義されているかどうかを定義しました。 ）。これをサポートするために、メタデータテーブルにリンクされたリストのオプションを含む追加のテーブルがあります。

Answer 3

ユーザーが値を入力できる2つのテキストボックスしか持っておらず、文字列または数字のいずれかである場合、intとdoubleを区別できる必要がありますか？適切な数値タイプ（DBに依存）。これにより、わずか2種類のタイプになり、可能なソリューションは2つのテーブルを持つことです。

一般的に、どのようなデータタイプが何かがあるかを知るのが難しいとわかるときはいつでも、プロジェクトが非常に乱雑になる傾向があるジェネリックになろうとしているのではないかと心配し始めます。

Answer 4

私の見解を提供する前に..私はあなたがERボードに戻る必要があるかもしれないと言うでしょう。私はa カスタムフォーム 多くを持っています 田畑 そして、これら 田畑 概念を一般化するのではなく、異なる種類（テキスト、データ、おそらく行動、スタイル）があります 分野 代わりに、各タイプのフィールドに1つのテーブルを作成することを検討する価値があるかもしれません。たとえば、DateField、UsernameFieldなど。これにより、値タイプは正確に1つの非ヌル列になり、正しいタイプの列になります。また、これがあなたのコードを簡素化すると確信します（チェックする条件が少なくなり、DBがすべての情報を提供します。）

とはいえ、ERボードに戻ることができない場合や、複数の列型アプローチを実行する根本的な正当な理由がある場合があります。このようなアプローチの長所と短所を次に示します。

プロ

• すべて1つのテーブルで、 五月 より速くなることが判明しました（すべての悪の根を覚えていますが..）

短所

• DBは、1つ以下の値が指定されていないことを強制できません（例外を確認するための追加コード）
• DBは、少なくとも1つがnullではないことを強制できません（価値なしにフィールド値をチェックするための追加コード）
• 新しいデータ型のサポートを追加するには、既存のすべてのデータを変更する必要があります（列にヌル値を追加します）。

あなたがに固執している場合 カスタムフォーム > 分野->FieldValue 1つのテーブルを作成することをお勧めします FieldValue. 。例えば

IntFieldValue
-------------
Id
DataFieldId
Value

DecimalFieldValue
-------------
Id
DataFieldId
Decimal


DateFieldValue
-------------
Id
DataFieldId
Date

上記を使用すると、上記のテーブルから選択するビューを作成できます。ビューは、値タイプごとに1つの列を提供するために作成できます。 保証 そのうちの1つだけがヌルではありません。これも拡張しやすくなります（新しいテーブルを追加し、ビューを変更しますが、新しいタイプ列のnull値で既存のデータを更新する必要はありません）。