ここで、5NF、EAV、および 6NF に関する議論と、メタデータと複雑な SQL を「自動的に」処理するためのカタログの必要性を読みました。それは実際にどのように実装されていますか？
PerformanceDBA は、カタログに言及する 6NF および EAV に関するいくつかの回答を書きました。たとえば、次の質問です。
特に、PerformanceDBA が書いた複数の固定テーブルと柔軟な抽象テーブル
「たとえば、カタログを備えた 6NF データベースの場合、すべての SELECT を実行するために必要な SQL を [再] 生成する一連のプロシージャがあり、すべてのユーザーに 5NF でビューを提供するため、基礎となる 6NF 構造. それらはカタログから追い出されます. したがって、変更は簡単で自動化されています. EAV タイプは、カタログがないため、手動で行います.
まず、LedgerSMBでは、可能な限りシステム カタログと情報スキーマを再利用します。これは、アプリケーションが実際にシステム カタログのクエリにある程度の時間を費やしていることを意味します。拡張属性のメタデータ計算もいくつかあります。ここでは EAV を行いません。むしろ、クライアント側でリレーショナル クエリを作成できるようにする、これらに関する実際のリレーションとメタデータがあります。これらはある時点でロードされ、キャッシュされます。カタログは EAV カタログと非常によく似ていますが、基礎となるストレージは実際にはリレーショナルであり、これらを維持する関数は基礎となるテーブルを変更します。これにより、根本的な問題なしに EAV の柔軟性が得られます。
将来のバージョンでは、おそらくアプリケーション カタログの数を減らし、Pg システム カタログと情報スキーマをより多く使用するように移行し、インターフェースはアプリケーションの観点からよりシンプルになります。