これまでに見たことのないものがあります。データベースは本当に汎用的です。例: 具体的なタイプの代わりに、一般的なタイプのデバイスがあり、それはカスタム プロパティ テーブルに関連しています。
残念ながら、エンティティのモデルはこれらのテーブルを表しているため、モデルはビジネスについてまったく語っていません。
最後に、プログラミングは非常に混乱します。一般的なテーブルにあるはずのカスタム プロパティを誰も設計または定義していないため、どこに何を配置すればよいかわかりません。また、1 つの属性を取得するだけでも多くのコードが必要です。
汎用モデルを使用した汎用データベースは、ある種のアンチパターンだと思いますか? どんなプロ？
これは、内部プラットフォーム効果を思い出させます。基本的に、データベースは、具体的なタイプが実装されている2番目のデータベースシステムに縮小されます。
私は過去にかなり一般的なデータベースを扱っていました。これは、非常に頻繁に要件が変更され、予期しない相互接続が発生する巨大なシステムを管理する賢明な方法でした。
ただし、実行は3種類のテーブルでした。特定のデータ型を格納する主な「汎用」テーブル、リンクのテーブル（テーブルからのテーブル、リンクからのテーブル、テーブルへのリンク、レコードタイプ）、およびテーブルのテーブルで、どのタイプを定義するかデータの保存方法と保存方法。もちろん、これによっていくらかのオーバーヘッドが発生しましたが、これはエンジンのカスタマイズによって相殺され、一般的なリクエストを実際に高速化し、複雑なリクエストを妥当な (そして稀な) 状態に保ちました。
したがって、一般的な状況ではこれがアンチパターンであることに同意しますが、これが正しいことであるシナリオもあります。特定のシナリオの 1 つは、システムが一般的なプラットフォームであり、非技術者が一般的なブロックを組み合わせて新しいサービスを作成する場合です。ブロックは「データ型」テーブルに接続されていますが、これらのテーブルがどのように使用されるか (およびブロックに何が入力されるか) はユーザーに任されています。
一般的なドメインでない限り、アンチパターンのように聞こえると思います。これを、リレーショナル モデルにマップされた通常のオブジェクト/リレーショナル/オブジェクトと比較してください。ほとんどのテーブルは実際のドメイン エンティティを表しています。これははるかに直感的で、理解と保守が簡単で、(コーディングと実行で) すべてのオーバーヘッドを必要としません。