3

私のアプリケーションでは、ユーザーが壁紙をアップロードするたびに、その壁紙を 3 つの異なるサイズにトリミングし、それらすべてのパス (トリミングされた画像の 3 つのパスと元のアップロード壁紙の 1 つ) をデータベースに保存する必要があります。
元の壁紙 (ユーザーがアップロードしたもの) の tinyurl も保存する必要があります。

上記の問題を解決しながら、次のテーブル構造を考え出しました。

CREATE TABLE `wallpapermaster` (
  `wallpaperid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `userid` bigint(20) NOT NULL,
  `wallpaperloc` varchar(100) NOT NULL,
  `wallpapertitle` varchar(50) NOT NULL,
  `wallpaperstatus` tinyint(4) DEFAULT '0' COMMENT '0-Waiting,1-approved,2-disapproved',
  `tinyurl` varchar(40) NOT NULL
) ENGINE=MyISAM

wallpaperloc は、元の壁紙の場所とトリミングされたすべてのインスタンスの場所で構成されるカンマ区切りのフィールドです。

リレーショナル データベースの世界では、コンマ区切りのフィールドを使用するのは悪い設計と見なされていることを知っています。

4

5 に答える 5

4

Wallpapermasterとロケーションテーブルの間で1：nの関係を使用します。

このようなもの：

CREATE TABLE wallpapermaster (
  wallpaperid     int unsigned NOT NULL AUTO_INCREMENT,
  userid          bigint NOT NULL,
  wallpaperloc    varchar(100) NOT NULL,
  wallpapertitle  varchar(50) NOT NULL,
  wallpaperstatus tinyint DEFAULT '0' COMMENT '0-Waiting,1-approved,2-disapproved',
  primary key (wallpaperid)
) ENGINE=InnoDB;


CREATE TABLE wallpaperlocation (
  wallpaperid  int unsigned NOT NULL,
  location     varchar(100) NOT NULL,
  tinyurl      varchar(40),
  constraint fk_loc_wp 
      foreign key (wallpaperid) 
      references wallpapermaster (wallpaperid),
   primary key (wallpaperid, location)
) ENGINE=InnoDB;

の主キーはwallpaperlocation、同じ場所を2回挿入できないようにします。

int(10)データ型の制約は定義されていないことに注意してください。これは、クライアントアプリケーションが数字の桁数を示すためのヒントにすぎません。

于 2013-01-11T10:26:48.983 に答える
1

サムネイルはアップロードされた単一のファイルから自動的に生成されますが、トリミング/サイズ変更されたファイルへのパスを保存する必要はまったくありません。

代わりに、サムネイルに正規化されたファイル名を使用して、ファイルシステムでそれらを見つけることができます-KingCrunchが提案したもの：photo1.jpgなどphoto1-medium.jpg。

とにかく、私の2cc：いくつかのハーベスターで画像ライブラリ（および作成されたサムネイル）をトラバースすることを避けるために、プログラムでMD5 +いくつかの秘密鍵だけでも各サムネイルの名前を暗号化することをお勧めします。そうすれば、鍵を知っているプログラムだけが適切に作成できます。元の名前/パスに基づいたサムネイルへのパス。他のクライアントの場合、命名順序はランダムになります。

于 2013-01-14T22:22:25.763 に答える
1

通常、固定の場所（おそらく構成外）、修正の拡張子（通常jpg）、およびのような特別なファイル名形式を使用します[name]-1024x768.jpg。このようにあなたは名前だけ

于 2013-01-11T10:22:21.523 に答える
1

私の意見では、単純なアプリケーションを使用すること;は、リレーショナル データベースであっても非常に優れたソリューションです。,

おそらく、分割された画像の数について考える必要があります。壁紙が 5 枚未満の場合は、オーバーヘッドの複雑なソリューションは使用しません。

  • データベースとアプリケーションでの保守は簡単です。文字列splitting/joiningメソッドを使用します
  • join値を取得するために使用する追加のテーブルを追加する必要はありません。
  • アプリケーション データベース アクセス エンジンに依存する必要がないため、simple を使用するvarchar方が適切です。ORMまたはJDBCxmlを使用する場合、より複雑なデータ型を処理するために追加の作業を行う必要があります。

より複雑なシステムでは、XML列を作成します。

于 2013-01-11T10:27:19.800 に答える
0 
CREATE TABLE `wallpapermaster` (
  `wallpaperid` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `userid` bigint(20) NOT NULL,
  `wallpapertitle` varchar(50) NOT NULL,
  `wallpaperstatus` tinyint(4) DEFAULT '0' COMMENT '0-Waiting,1-approved,2-disapproved',
  `tinyurl` varchar(40) NOT NULL
) ENGINE=MyISAM

「wallpapermaster」テーブルとの関係を作成する新しいテーブルを作成します 

create wallpapermaster_mapper( 
    `id` unsigned NOT NULL AUTO_INCREMENT,
    `wallpapermaster_id` int(10) //this will be foreign key with id of wallpapermaster table
    `wallpaper_path1`  varchar(100) NOT NULL,
    `wallpaper_path2`  varchar(100) NOT NULL,
    `wallpaper_path3`  varchar(100) NOT NULL,
    )
于 2013-01-11T10:24:57.647 に答える