0

のようなテーブルがありCustomer、Purchaseドキュメントが関連付けられていることがあります。ドキュメントとは、どこかにあるファイルを意味します（スキャンされた運転免許証など）

アプリケーションにこれらのドキュメントをデータベースに直接アップロードさせることはできないため、代わりにこれらの一意の識別子列を使用します（代わりにファイルハッシュを使用する必要がありますか？）

私の質問：
将来、テーブルに関連付けられたドキュメントが増える可能性があるため、次のようなフィールドを追加することを考えていました。

顧客
+DriversLicenseDoc
+ Document1//将来のために
+Document2//将来の使用

したがって、将来、別のドキュメントが必要であると彼らが判断した場合は、エンティティフレームワークモデルを更新し、モデルの列の名前を変更するだけで、データベースを変更する必要はありませんか？

これは一般的にどのように行われていますか？より良いアイデアはありますか？私が見る欠点は、これらすべての将来の値をnull許容に保つ必要があるということです。多分それは欠点ではありませんか？
また、展開後のデータベーススキーマの変更に一般的にどのように対処するかについての考えを聞きたいですか？

4

1 に答える 1

4

いいえ、それは実際には本当に悪い考えです。正しく使用することを予測している場合は、意図したとおりに追加するか、何が起こるかを推測しているだけです。その場合は、わかるまで待つ必要があります。

デプロイメント後にスキーマの変更を処理する方法は、デプロイメント後にスキーマ（および関連するコード）を変更することです。頭字語「YAGNI」を調べてください。私の意見では、すぐに必要とされない努力は、決して必要とされないかもしれない何かのために実行された努力と見なされるべきです。言い換えれば、無駄な努力。

存在する可能性のあるドキュメントの数が不明な場合、これは、customersテーブルからdocumentsテーブルへの単純な1対多の関係であり、テーブル内の各ドキュメントには、次のようなドキュメントタイプとドキュメントペイロードが含まれます。

customers:
    custid  primary key
    <all other customer data>
documents:
    docid primary key
    custid references customers(custid)
    <all other document data>

そうすれば、各顧客は、必要な数の種類のドキュメントを必要な数だけ持つことができます。

于 2010-12-19T12:06:11.153 に答える