これは複雑な問題なので、単純化してみます。
サーバー上に、さまざまな目的で多数のスキーマをホストしているmysqlインスタンスがあります。スキーマは一般的に（完全ではありませんが）EAV方式で構造化されています。定期的に情報をその構造に出し入れする必要があります。
例1：Webページに情報を表示するために、情報を取得して複雑なオブジェクトに貼り付け、jsonを介してWebページに渡します。ここで、jsonを複雑なjavascriptオブジェクトに変換し、次に表示します。knockoutjsと同様のもの。
結論：これにより、ページ上の値をデータベース内の値に関連付けることができるように、多くのロジックが複数の場所に配置されました。
例2：ユーザーがPDFから情報をインポートできるようにするために、PDFフォームフィールドに多くの情報を保存しています。この場合、私はpdfを作成しなかったので、フォームフィールドは、このロジックのすべてがCRUDに対して3回以上作成するのに十分簡単な方法で名前が付けられていません。
結論：これにより、pdfフォームフィールドのリストをデータベース内のテーブルにコピーし、データを配置する場所にそれらを何らかの方法で関連付けることができました。発生した問題は、PDFのフィールドをschema.table.columnに関連付ける必要があり、その情報を格納するために私が見つけた唯一の方法はVARCHAR経由であったことです。
どちらの例も少量のデータを参照していません（例1の6つのテーブル、例2の約1400のpdfフォームフィールドなど）。Example1と結果のロジックが複数の場所に格納されていることを考えると、Example2を構築するのは理にかなっているように見えました。ここでは、データベース内のデータ間の関係を格納して、一貫して、関連するすべてのメソッドにアクセスして変更することができます。
さて、私が愚かである可能性が非常に高く、すべてのグーグルがこのデータを正しいschema.table.columnに関連付ける簡単な方法があることに気づいていません。その場合は、正しい方法を教えてくださいそれを行うには、ここで簡単な答えがあります。
しかし、これは私が混乱するところです。特に文字列（varchar）としてではなく、データベースに関する情報をデータベースに保存したくないといつも言われています。これは非常に多くのレベルで間違っているように思われ、私が愚かであるかどうかを理解できません。例1に従うか、データベース構造について見逃したトリックがあるかどうかを確認することをお勧めします。