データベースを強制的にビジネスロジック、良いアイデア、または愚かなものに従うための「ダミーレコード」を作成するのでしょうか？

Question

一部のプロジェクトでは、DBの制約を破らずにビジネスロジックを続けるために、DBで作成するためにダミーレコードが必要であることがわかります。

これまでのところ、私はその使用法を2つの方法で見てきました。

• isdummyのようなフィールドを追加します
• フィールドを追加することにより、タイプを指すObjectTypeと呼ばれるもの：ダミー

わかりました、それは達成する必要があるものに役立ちます。

しかし、私がそのようなソリューションで警戒心を感じさせるのは、いくつかのプロセスで処理する必要があるアプリケーションにいくつかのダミーレコードが存在することを念頭に置いておく必要があることです。そうでない場合、あなたは彼らの存在に気付くまで、またはチームの誰かがあなたに言うまでいくつかの問題に直面します」ああ！ダミーレコードを忘れてしまいました。あなたもやるべきです..."

質問は次のとおりです。DBに不満を言うことなく、ビジネスロジックを維持するためにダミーレコードを作成することは良い考えですか？はいの場合、開発者が自分の存在をスキップするのを防ぐためのベストプラクティスは何ですか？そうでない場合、ダミーレコードを作成する唯一のオプションになってしまう状況に陥るのを防ぐために、あなたは何をしますか？

ありがとう！

Answer 1

ダミーレコードを使用することは、制約を正しくすることよりも劣っています。

ダミーレコードを使用することは新しい機能を提供する最速の方法のように見える可能性があるため、それらを使用する誘惑がしばしばあります（そして、おそらくそうであるかもしれません）、それらは決して 良い ドメインロジックとデータモデルの違いを非表示にするため、設計します。

Answer 2

ダミーレコードは、モデラーがデータベース定義を簡単に変更できない場合にのみ必要です。つまり、定義および/またはデータモデルがかなり悪いことを意味します。データベース内の特別なケースを処理するためにアプリ層に特別なコードが必要な状況に終わることはありません。それは保証されたメンテナンスの悪夢です。

優れた定義またはモデルは、「既存のコードに影響を与える」ことなく、簡単に変更を可能にします。

すべてのビジネスロジック[データベースで定義されている]は、ANSI SQLの制約、チェック、およびルールを使用して実装する必要があります。 （もちろん、低レベルの構造はすでにドメイン/データ型などを介して制約されていますが、「ビジネスルール」として分類することはありません。）私は、それを行うだけで、ダミーを実装する必要がないことを確認します。

それができない場合、モデラーには知識と経験がありません。または、正規化などのより高いレベルの要件が破られており、それはそれらに依存する制約を実装する障害を示しています。また、モデラーが失敗したことを意味します。

このような制約を破る、ダミーレコードを追加する必要はありませんでした（そして、私は非常に多くのデータベースに取り組んできました）。他の人が作成したデータベースを作り直したときに、ダミーレコード（および複製）を削除しました。

Answer 3

私はこれをしなければならないことに遭遇したことがありません。これを行う必要がある場合、データ構造に何か問題があり、報告のためにさらに問題を引き起こすでしょう...

Answer 4

ダミーの使用は愚かです。

一般に、あなたはそれらなしであなたの論理を正しくすることを目指すべきです。私もそれらが使用されているのを見てきましたが、緊急解決策としてのみです。あなたの説明は、それを標準的なプラクティスにするのと同じように聞こえます。それは解決するよりも多くの問題を引き起こすでしょう。

Answer 5

「ダミー」レコードを追加することでわかる唯一の理由は、非常に悪いアプリとデータベースデザインがある場合です。

それは間違いなく一般的な慣行ではありません。

ビジネスロジックが存在するレコードに依存している場合は、2つのことのいずれかを実行する必要があります。そのロジックを実行する前に正しいレコードが作成されていることを確認してください。または、ロジックを変更して、欠落している情報を考慮します。

Answer 6

「ビジネスロジック」がより良い方法を考えようとする原因として、何かが非常に簡単に区別できない状況はどんな状況だと思います。

「タイプを指す：ダミー」に言及するという事実は、データアクセスを処理するために何らかのORMを使用していると信じるようになります。 NhibernateのようなORMソリューションの非常に優れたチェックポイント（唯一ではありませんが）は、ソースコードがアプリケーションを駆動するデータ構造を非常に明示的に説明していることです。これにより、データアクセスをソース制御の下で簡単に管理できるようになるだけでなく、問題が発生した場合にラインを簡単にデバッグすることができます（そして、それに直面してみましょう。問題が発生するかどうかは問題ではなく、いつ発生するかということです）。

ダミーレコードのようなある種の「松葉杖」を導入すると、データベースのポイントを無視しています。この種のことの必要性を排除するために、データベースがデータに対するルールを実施するためにあります。この種のテクニックに頼る前に、最初にアプリケーションロジックを見ることをお勧めします。仲間の開発者、または新規採用について考えてください。機能を追加し、小さな「ダミーレコード」ロジックを忘れる必要がある場合はどうなりますか？

あなたはあなたの質問で自分自身に懸念を感じています。あなたの腸と一緒に行きなさい。ダミーレコードを取り除きます。

Answer 7

私はここで共通の感情に行き、ダミーの記録に反対しなければなりません。

何が起こるかは、新しい開発者がそれらについて知らず、それらを処理するコードやテーブルを削除して新しいダミーレコードを追加することを忘れないことです。

私はそれらをレガシーデータベースで経験しましたが、上記の両方が起こるのを見てきました。

また、それらを取り出すのが難しく、それらを取り出すのが難しくなり、これらのダミーレコードを考慮に入れるには、より多くのコードを書く必要があります。

Answer 8

正しい解決策は、ビジネスロジックを更新することです。

拡張された説明を引用するには：

パッケージオブジェクトがあり、コンテンツのないパッケージを作成できないというビジネスロジックを実装していると仮定します。いくつかのビジネスレイヤールールを作成し、関連する制約を備えたDBを設計しました。しかし、数年後、新しい機能が要求され、それを達成するためには、コンコーなしでパッケージを作成できる必要があります。これを克服するために、UIでは見えないが空のパッケージを作成できるダミーコンテンツを作成することにします。

したがって、一度にコンテンツを含むパッケージのパッケージのために、パッケージオブジェクト内のコンテンツの存在を強制するビジネスレイヤーが強制されました。それは理にかなっている。現実世界のシナリオが変更された場合、コンテンツなしでパッケージオブジェクトを作成する必要がある正当な理由があります。これは、変更する必要があるビジネスロジックレイヤーです。

ほぼ普遍的に「ダミー」を使用するのはどこでも悪い考えであり、通常は実装の問題を示します。この例では、ダミーデータを使用して、ビジネスの現実世界の制約を正確に表していないビジネスレイヤーを使用して「コンプライアンス」を許可しています。

コンテンツのないパッケージが有効でない場合は、ビジネスレイヤーを使用した「コンプライアンス」を許可するダミーデータは愚かなハックです。本質的に、あなたはあなた自身のシステムを保護するためのルールを書きました、そして、あなた自身の保護をどのように回避しようとしていますか。一方、コンテンツのないパッケージが有効な場合、ビジネスレイヤーが偽の制約を施行してはなりません。どちらの場合も、ダミーデータは有効ではありません。