予約ソフトウェアにカスタムフィールドを実装する必要があります。たとえば、動的属性を持つユーザーグループを含むいくつかのテーブルを拡張する必要があります。
ただし、各商品にカスタムフィールドを含めることができる商品テーブル（理想的には、これらのフィールドをネストすることもできます）。
すでにEAVについて検索をしましたが、ネガティブなコメントをたくさん読んだので、このようなものにどのデザインを使うのか気になります。
EAVを使用すると、製品のページを並べ替えるために多くの結合が発生することは理解していますが、属性が作成されるたびにグループ/製品テーブルを変更したいとは思いません。
注：私はInnodbを使用しています
唯一の良い解決策は、属性が作成されるたびに、グループ/製品テーブルを変更するという、ほとんどやりたくないことです。はい、それは苦痛ですが、データの整合性とパフォーマンスの向上を保証します。
それをしたくない場合は、を使用してテーブルを作成し、次のようTableName, FieldName, ID and valueに保持することができます。
TableName ='Customer'、FieldName ='Address'、ID = 1（customers ID）、Value ='customers address'
しかし、あなたが言ったように、それはたくさんの結合を必要とするでしょう。私はそれが良い解決策ではないと思います、私はそれを見ましたが、それを本当にお勧めしません。まあ、それは一つの可能な解決策だからです。
別の解決策は、などのようにテーブルにいくつかの事前定義された列を追加column1, column2, column3し、必要に応じてそれらを使用することです。これは前のソリューションと同じくらい最悪のソリューションですが、それを使用する主要なERPを見てきました。
メイト、経験に基づいて、この領域で見つけたものはすべて回避策であり、実装する価値はありません。それを維持する必要がある頭痛は、フィールドをテーブルに追加するよりも大きくなります。シンプルで正しいものにしてください。
私は完全にEAVに基づいたプロジェクトに取り組んでいます。EAVは物事を複雑で遅くすることに同意しますが、新しい属性を追加するためにデータベース構造やコードを変更する必要がなく、データベーステーブル内のデータ間に階層を設定できるなどの独自の利点があります。
すべての場所でEAVを使用している場合、システムが非常に遅くなる可能性があります。
しかし、賢明に使用すれば、Eavは非常に役立ちます。EAVに基づいてDB全体を設計することは決してありません。共通の有用な属性を分割してフラットテーブルに配置し、追加の属性（クライアントやさまざまな要件によっては変更が必要になる場合があります）にはEAVを使用します。
このようにして、多くの問題を起こすことなく、必要な柔軟性を含むEAVの利点を得ることができます。
これは私の提案です。もっと良い解決策があるかもしれません。
これを行うには、少なくとも2つのテーブルを追加します。1つのテーブルには、属性の一意のキー（attr_id）と、属性名やビジネスロジックに必要なその他の属性値などの属性値が含まれます。
2番目のテーブルは、say productsテーブルとattributesテーブルの間の結合として機能し、次のフィールドが必要です。
(id, product_id, attr_id)
このようにして、必要な数の動的属性を追加でき、データベーススキーマは将来にわたって利用できるようになります。
クエリの唯一の欠点は、結合するテーブルをさらに2つ追加する必要があることです。