次の状況で、2つのdbスキーマアプローチのどちらを採用すべきかについて混乱しています。
Webサイトの複数の属性（ページサイズ、単語数、カテゴリなど）を保存する必要があり、属性の数は将来増加する可能性があります。目的は、このテーブルをユーザーに表示することであり、ユーザーはデータ間ですばやくフィルター/並べ替えを実行できる必要があります（したがって、テーブル構造は高速のクエリと並べ替えをサポートする必要があります）。また、変更のタイムラインを維持するために、以前のデータのログを保持したいと思います。したがって、私が考えた2つのテーブル構造オプションは次のとおりです。
オプションA
website_attributes
id、website_id、page_size、word_count、category_id、title_id、......（最大18列になり、null値がいくつかある可能性があり、将来的にさらに列を追加する必要がある可能性があることに注意する必要があります）
website_attributes_change_log
上記と同じテーブル構造に「change_update_time」の列が追加されています
このスキーマの利点は、一部の属性が他のテーブルにリンクされている場合でもクエリを簡単に記述できることと、並べ替えが簡単になることです。後で列を追加することの欠点は、ALTERTABLEが大きなデータテーブルで実行するのに非常に長い時間がかかることで問題になる可能性があります+多くのnull列を持つ多くの行が存在する可能性があります。
オプションB
website_attribute_fields
attribute_id、attribute_name（eg page_size）、attribute_value_type（eg int）
website_attributes
id、website_id、attribute_id、attribute_value、last_update_time
ここでの利点は、いつでも列を追加でき、ストレージスペースを節約できるという点で、このアプローチの柔軟性にあるようです。ただし、このアプローチを採用したいのですが、テーブルを表示する必要がある場合、クエリの記述は特に複雑になると思います[一度に複数のサイトのレコードを表示する必要があり、相互参照もあるためです。特定の属性の他のテーブルとの値の比較]+データの並べ替えは難しい場合があります[これが列ベースのアプローチではない場合]。
私が見ているもののサンプル出力は次のようになります。
Site-A.com、232032バイト、232ワード、PR 4、不動産[カテゴリテーブルにリンク]、..
サイト-B.com、...、...、...、..。
また、ユーザーはすべての数値ベースの列で並べ替えることができる必要があります。その場合、アプローチBは難しい場合があります。
ですから、私はオプションAを使用して正しいことをしているのか、それともそもそも考えもしなかったかもしれない他のより良いオプションがあるのかを知りたいのです。