2009-06-03 17 views
4

「記事」の典型的な荒れ果てたアプリを作成する必要があります。これには標準やベストプラクティスがありますか?私はすべてのアプリと状況が異なることを知っているが、私は一般的に意味する。記事テーブルスキーマ

第2に、特定の記事に関連する複数の画像を扱う方法がちょっと混乱しています。イメージテーブルと画像と記事を参照するのではなく、すべてのこと。この種のものを扱う方法に関するいくつかのヒントや提案を探してみてください。ここのほとんどの人がこれを何度もやっていると確信しています。

としての私の記事の定義は次のとおりです。

CREATE TABLE `articles` (
    `id` int(11) NOT NULL auto_increment, 
    `issue_id` int(11) default NULL, 
    `status` text, 
    `updated_at` date default NULL, 
    `body` text, 
    `title` varchar(255) default NULL, 
    `author` varchar(255) default NULL, 
    `created_at` date default NULL, 
    PRIMARY KEY (`id`) 
) 

答えて

1

記事テーブル:

CREATE TABLE `articles` (
    `id` int(10) unsigned NOT NULL auto_increment, 
    `keyname` varchar(96) NOT NULL, 
    `title` varchar(96) NOT NULL, 
    `content` text NOT NULL, 
    `tags` varchar(128) NOT NULL, 
    `author` varchar(128) NOT NULL, 
    `date_created` datetime NOT NULL, 
    `date_updated` datetime default NULL, 
    PRIMARY KEY (`id`) 
) 

記事の画像:

CREATE TABLE `articles_images` (
    `id` int(10) unsigned NOT NULL auto_increment, 
    `article_id` int(10) unsigned NOT NULL, 
    `url_thumb` varchar(512) NOT NULL, 
    `url_big` varchar(512) NOT NULL, 
    `date_created` datetime NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `article_id` (`article_id`) 
) 

url_thumb - 画像のサムネイル
url_big - 大きな画像

そして、あなただけの画像を表示し、必要な場合は、画像タグ事が

細かいFTPでアップロードしたい場合は、Wordpress`データベースchema

+0

私はタグをタグごとに1つの異なるテーブルに分割しました。 –

+0

コンテンツ内のimgタグとは対照的に、画像やそのパスをテーブルに保存する理由は何ですか?私はちょうどポイントを見ていない、私はあなたが記事に関連付けられている5つの画像があると言うことを意味します – Ronn

+0

はい、そのベストプラクティスではなく、リストのようないくつかの他のページにそれらの画像を注入することは非常に便利です。画像ギャラリーを作成することさえできます。話題が始まって共通の解決策が尋ねられましたが、あなたのサイトがブログではない場合はもちろんありません。 と要点は - 多くの画像解像度を追加して、いつでもどこでも使用できます。多分私はあまりにも具体的です。 –

0

をチェックアウトすることができますWebインターフェイスを使用してアップロードすると、DB内のパスを保存するのが非常に便利です

イメージ自体を記事に添付する必要はありません。イメージパスを保存して、結合モデルを使用するか、画像タグを介して画像に転送する

これは、あなたがアップロードして保存

2

Dublin Coreを処理するためにペーパークリップほど便利なもの(プラグイン)を使用することができますが、文書やメディアの属性の非公式の標準セットです。属性は以下のとおりです。

  • タイトル
  • クリエーター
  • 件名
  • 説明
  • 出版社
  • コントリビュータ
  • タイプ
  • フォーマット
  • 識別子
  • ソース
  • 言語
  • 関係
  • カバレッジ
  • 権利

この背後にある年のドキュメント/メディア管理アプリケーションを実行した人々からの思考の公平なビットがありますリスト。私は、あなたが最初に見逃してしまう可能性のある属性(クリエイター対パブリッシャー対ソース)のアイデアを精査するのは良い資料だと思います。私はそれらが関連しているかどうかを考えずに、あなたのアプリケーションにすべてのものをダンプするだけではありません。

私は記事に記事を関連付けるテーブルが必要だと思います。そうでない場合は、記事や画像を削除するなど、記事がどの画像を使用しているかを知る必要がある場合は、関連する画像を見つける唯一の方法は記事本体自体を解析することです。これは、文字列処理関数を使用する厄介なSQLのために、またはあなたの記事を一度に処理する必要がある場合、両方ともパフォーマンスの問題になる可能性があります。

イメージボディのイメージタグを使用してイメージをレイアウトすることはできますが、それ以上複雑なカスタムマークアップシステムを使用することはできません。モデルを作成して、画像タグを解析し、記事の作成/編集時に結合テーブルを更新するだけです。少しノコギリとattachment_fu(またはそれらの代替)は、これをすばやくする必要があります。