データベースにメタテーブルを作成するための提案はありますか？これらのテーブルは、データベースを使用して、データベース内のテーブルをエミュレートするために使用されます。これは、関連するすべての技術を気にすることなく、その場でデータベースに構造（より多くのフィールド）を簡単に追加したい場合に使用します。私が持っている唯一の例は次のようになります：
テーブル：MetaTablesフィールド：tableName、tableDescription
テーブル：MetaFieldsフィールド：tableName、fieldName、fieldDesc、fieldDesc
テーブル：MetaCodesフィールド：tableName、fieldName、codeName、codeValueなど...
私はこれまでこのようなものを実際に使用したことがなく、注意すべき「落とし穴」があるかどうか疑問に思っていました。
このようなものは合理的に保守可能ですか、それとも反対にアドバイスしますか？
あなたが話しているのは、オープンスキーマモデルまたはエンティティ属性値モデルと呼ばれることが多い柔軟なスキーマモデルです。それらをグーグルすると、あなたはたくさんの参考文献や記事を手に入れるでしょう。
また、列を追加するデザインを恥ずかしがらないようにすることをお勧めします。設計の変動性のレベルがそれほど重要ではない場合、人々がこのようなアプローチをとるのをよく目にします。新しいデータコンテナ（テーブル、列など）の作成をスクリプト化することは、それほど難しくありません。
完全に実装されたリレーショナル データベースを使用して、ほとんどすべての機能を無視し、リレーショナル データベースの上に独自のリレーショナル データベースを構築するという考えは、発生するのを待つのが難しいと思います。
独自のモデルを構築するのは「クール」に聞こえます。
もちろん、独自のメタレベルのスペース管理を構築する必要があります。中程度の首の痛みです。
クエリの実行、最適化、インデックスの処理などは比較的複雑です。
次に、トランザクション、ロック、デッドロック検出などがあります。これを正しくするのは本当に難しいです。しかし、それが機能するようになると、大きな「クール」な要素が生まれます。
また、API を発明する必要があります。ODBC は低レベルで動作し、より高いレベルで動作する必要があるため、ODBC の独自の「クールな」バージョンを発明する必要があります。
「クール」な要素は、この作業のすべてに勝るものでした。これを機能させるには何年もかかります。
ほとんどの場合、メタテーブルスキーマは、そもそもリレーショナルデータベースを使用するという目的に反します。基本的なトランザクション/ACIDプロパティとは別に、リレーショナルデータベースは、システムに2つの大きな機能を追加するのに最も役立ちます。a）レポートジェネレータなどのアプリケーションとデータを共有すること、およびb）アドホッククエリを可能にすることです。
上記の2つがどちらも当てはまらず、一般的なものにしたい場合は、他のデータ永続性ソリューションの方が適している可能性があります。Berkley DBのようなもので独自のソリューションを非常にエレガントにロールするか、一般的なスキーマのバリエーションを試すことができます。
http://theprogrammersparadox.blogspot.com/2008/06/structuring-noun-verb-data.html
ポール。
keithwarren7 が示唆したように、いくつかの Google を実行すると、(コメントによると) これを行うのはまったくクールではないことがわかります。（わかりました、場合によってはそうですが、ほとんどの場合そうではありません.IMO.）
優れているのは、考え抜かれたスキーマ設計でリレーショナル データベースを意図したとおりに使用することです。これにより、データの整合性とパフォーマンスが向上し、ストレージの使用量が少なくなり、一般に、Entity-Attribute-Value モデルよりも操作がはるかに簡単になります。あなたが読むいくつかの明らかな落とし穴があります。たとえば、データベースではなく、自分で参照整合性を強制する責任があります。
いずれにせよ、このアイデアを (stackoverflow を超えて) 慎重に調査してから、先に進んでください。一度このように実装すると、気が変わるのは非常に大きな問題です。
EAVはかっこいいように見えますが、かっこいいとは言えないというコメントに同意します。それは、限界以下または完全に逆効果であることが判明した多くの作業を行っています。
メタデータを含む独自のユーザーテーブルを使用したのは、2つの異なるデータベースを比較して、それらがどこで分岐しているかを確認するためです。2つの同じ構造のスキーマ間で値を比較するのは簡単です。スキーマ間の違いの検出はより微妙であり、メタデータの比較が含まれます。
私のアプローチは、2つ以上のデータベースのメタデータテーブルから「メタデータベース」のユーザー定義のメタデータテーブルにデータをコピーしてから、比較に進むことでした。約1時間で、一方のデータベースで実数として定義され、もう一方のデータベースで整数として定義された列を見つけました。これは何ヶ月もの間DBAから隠れていました。また、いずれかのデータベースから欠落している列がいくつか見つかりました。
今日、この種の比較を行うツールがあります。しかし、DBMSが作成するシステムテーブルのスキーマを理解していれば、自分で作成するのはそれほど難しくありません。
テーブルとフィールドを使用して動的構造を表現する代わりに、常に XML データの単一フィールドを使用できます。多くの主流の RDBMS では、XML 内の属性/要素のインデックス作成が許可されているため、クエリのパフォーマンスが向上する場合もあります。
申し訳ありませんが、他の投稿者が指摘しているように、車輪の再発明です。
このデータを使用する場合、ほとんどのデータベースには、データベース スキーマを含むテーブルがあります。これは、反射の目的で使用できます。
これらのテーブルへのアクセス方法は、適切なデータベース マニュアルに記載されているはずです。
1 つの大きな eav テーブルで大規模なデータセットを使用して、いくつかのパフォーマンス テストを実行します。上司がパフォーマンスの低下を見た場合、「クール」という言葉を使用することはありません。