1

基本的に、下の画像は、私が取り組んでいるサイトのホームページのコンポーネントを表しており、いたるところにニュース コンポーネントがあります。SQL のスニペットは、私がどのように機能すべきかを想定していますが、以前にニュース サイトで作業したことのある人からビジネス ロジックに関するアドバイスをいただければ幸いです。これが私がそれをどのように想像するかです：

代替テキスト

質問 #1 : SQL ロジックは理にかなっていますか? あなたが見ることができる警告/欠陥はありますか?

私のスキーマは次のようになります。

articles:

article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1

すべての記事 (主な特集、副次的な特集、残り) を 1 つのテーブルに格納typeし、テーブル内の番号に対応する列でそれらを分類しnews_typesます (この例では、理解しやすいようにリテラル テキストを使用しました) ）。

質問 #1.1 : 異なる種類の記事について 1 つのテーブルに依存しても問題ありませんか?

ニュース記事には、次の 3 種類の画像を含めることができます。

  • 記事のパーマリンク ページにのみ表示される 1x 元の画像サイズ
  • ホームページ セクション #1 に表示される 1x メインのアイキャッチ画像
  • ホームページ セクション #2 に表示される 1x サブ特集画像

今のところ、各記事を複数ではなく 1 つの画像に対応させたいと考えています。ただし、ユーザーは記事の画像をarticle_fullTEXT 列に投稿できます。

質問 #1.2 : 記事の画像をスキーマに組み込む方法がわかりません。このような 2 つのテーブルに依存するスキーマは一般的ですか?

article_image_links:

article_id article_image_id
1          1

記事の画像:

article_image_id article_image_url
1                media.site.com/articles/blah.jpg

データの要件:

私がSQLロジックを持っている方法から、ものが表示されるためにはいくつかのデータが必要です..

  • there has to be at least one main type article
  • there has to be at least four featured type articles which are below the main one

Question #1.3: Should I bother creating special cases for if data is missing? For example, if there's no main featured article, should I select the latest featured, or should I make it a requirement that someone always specify a main article?

Question #1.4: In the admin, when a user goes to post, by default I'll have a dropdown which specifies the article type, normal will be pre-selected and it will have the option for main and featured. So if a user at one point decides to change the article type, he/she can do that.

質問 #1.5 : 特集記事とメイン記事が最新の日付でしか機能しません。たとえば、ユーザーがなんらかの理由で古い記事をメインの記事として指定したい場合、カスタム ロジックを作成するか、記事の日付を最新のものよりも遅くなるように更新するように指示する必要がありますか?

4

1 に答える 1

1

タイトルの質問に関しては、猫の皮をむく方法は間違いなく複数あります。あるサイトに適したものが、別のサイトには適していない場合があります。決定の要因として考えられるのは、サイトをどれだけ大きくする必要があるか (たとえば、何十もの記事にするか、何百万にするか) と、誰がデータを入力するか (たとえば、どれだけのばか防止機能を構築する必要があるか) です。の）。いただいた情報をもとに、できる限りお答えしたいと思います。

質問 1:はい、問題ないように見えます。必ずインデックスを設定してください ([type,date] と [category,type,date] にインデックスを設定します)。

質問 #1.1:はい、それでいいと思います。実際、それが好ましいと思います。質問を正しく理解していれば（これは各「タイプ」の表とは対照的です）、必要に応じて将来新しいタイプを追加するための準備が整います。

質問 #1.2:各ストーリーに 1 つの画像、各画像に 1 つのストーリーのみが必要な場合、それを別のテーブルに分割する利点がわかりません。オーバーヘッドが増えるだけのようです。しかし、ここで何かが欠けている可能性があります。

質問 #1.3:それはあなた次第の設計上の決定です。ここに「正しい」答えはありません。それはすべて、システムの使用目的によって異なります。

于 2010-02-05T21:59:11.210 に答える