最近、サイトの管理者が何かを「特集」できるように、何かを追加するように依頼されました。
この議論では、それが「特集記事」であるとしましょう。
当然のことながら、「記事」のデータベースモデルはすでにあり、そのままで約20列あるので、これ以上肥大化する気はありません。
私のオプション:
「注目の」bool (または int) を追加して、特定の時点で注目されるのは 1 つだけであることを認識します。
これを保持する新しいモデルを作成し、ポップアップする可能性のあるその他のフィーチャー クリープ アイテムを作成します。
私はあなたの提案を取ります！;)
この場合、あなたはどうしますか？私は時々これに出くわしますが、何かにもう1列追加する必要があるのは嫌いです. この情報は永続化する必要があります。
おそらく、基本的にキー値ストアである単純な 2 列のテーブルを追加するだけです。(featured_article_id, 45)次に、最初の特徴的な ID などの値を持つ新しい列を追加します。
編集: rmeador のコメントで指摘されているように、物事が比較的単純である限り、これは良い解決策にすぎないことに注意してください。より複雑なデータを保存する必要がある場合は、より柔軟なソリューションを考え出すことを検討してください。
一度に 1 つの記事しか取り上げられない場合、bool 列を追加するのは無駄です。レベルを上げて、FeaturedArticleID の列を追加する必要があります。Site_Settings テーブルはありますか?
このような手っ取り早いもののために、私はある種の設定テーブルを含めるのが好きです：
CREATE TABLE Settings (
SettingName NVARCHAR(250) NOT NULL,
SettingValue NVARCHAR(250)
)
グローバル設定ではなく、ユーザーごとまたは顧客ごとの設定が必要な場合は、その特定のユーザー/顧客に対してそれを識別するための列を追加できます。次に、「FeaturedArticle」の行を追加して、文字列からIDを解析できます。あまり最適化されていませんが、平文は非常に柔軟性があり、まさに必要なもののように聞こえます。
属性のテーブルを持つような拡張可能なモデルを使用し、次にリンク テーブルを使用して、記事と属性の間に多対多の関係を形成できます。このように、これらの種類の機能では、スキーマを変更する必要はありません。
parameter_name 列と parameter_value 列を持つある種の global_settings テーブルを用意します。ここに特集記事のIDを入れてください。