Scroll
1.6. 製品とカテゴリー — DB テーブルを作成する
製品とカテゴリーの機能を作る前に、私たちの顧客とサイト管理者が必要とする情報について考えてみましょう。商品について十分な情報を提供する必要があり、商品名、商品の詳細な説明、商品の価格を表示しなければなりません。商品の写真や追加の画像を掲載することもできます。配送料の計算のために商品の重量が必要になるかもしれません。在庫がない商品を売らないよう、倉庫の在庫数も必要です。サイト管理者には商品の ID と、検索エンジン向けの人間が読める URL が必要になります。
結果として、少なくとも次のフィールドが必要になります:
| データ | 説明 |
| ID | サイト内部処理用の商品番号 |
| Name | 商品名 |
| 人間可読 URL | 主に検索エンジン向けに必要 |
| Description | 商品の詳細情報 |
| SKU | サイト利用者向けの商品品番 |
| Price | 商品の価格 |
| Stock | サイト上の商品数 |
| Primary image | メイン画像 |
| Additional images | 追加の画像 |
後続の記事でこのリストを拡張しますが、今のところはこれで十分です。
商品カテゴリーには独自のフィールドのリストがあります:
| データ | 説明 |
| ID | サイト内部処理用のカテゴリー番号 |
| Name | カテゴリー名 |
| Description | カテゴリーの説明 |
| 人間可読 URL | 検索エンジン向けの読める URL |
このまま先に進み、私たちのフレームワークを使って商品とカテゴリーを表示するためのデータ構造と機能を実装することもできますが、もし今それをすると、多くの柔軟性を失うことになります。ほとんどのコンテンツは多くの共通情報を表示します。その共通情報を見つけて抽象的なコンテンツタイプを作れば、フレームワークはより柔軟になります。コードを重複させることなく、これらのコンテンツタイプにさまざまな機能を使えるようになります。そうした機能には次のようなものが考えられます:
- コンテンツのバージョン管理
- アクセス権の区分け
- コンテンツ、ページ、商品へのコメント
- ページ、商品の評価
ページ
ページは、私たちのサイトの通常の静的なセクションになります。連絡先、配送と支払いの情報などです。これらのページのデータは次の表に示します:
| データ | 説明 |
| 名前 | ページ名 |
| 人間可読 URL | ページの URL |
| ID | ページの内部番号 |
| Heading | h1 タグの内容 |
| Title | <title> タグの内容 |
| Content | ページの内容 |
| Keywords | キーワードのメタタグの内容 |
| Description | 説明のメタタグの内容 |
Content
ページは、より多くのフィールドを保存する必要が出たときに拡張していく、基本的なコンテンツタイプです。カテゴリーページは本質的には同じページで、ただ商品と関連づけるためのフィールドがより多く必要になるだけです。
| データ | 説明 |
| ID | 内部処理用の番号 |
| Name | コンテンツ名 |
| 人間可読 URL | |
| Content | コンテンツページの内容 |
| Type | コンテンツのタイプ(例:page、product、category) |
| Order | コンテンツの並び順、例えばメニュー項目向け |
| Parent | コンテンツの親。階層のために必要、例えばサブカテゴリーやページのカタログ向け |
| Meta keywords | キーワード |
| Meta description | メタ説明 |
| Date created | 作成日 |
| Creator | コンテンツの作成者 |
| Active | コンテンツを訪問者に表示するかどうか |
| Secure | 権限を区分けするためのフィールド、例えば登録ユーザーのみ閲覧可にする |
リビジョン
Drupal にはリビジョンのシステムがあります。私たちにも同様の独自のシステムを用意します。
| データ | 説明 |
| ID | コンテンツの内部番号 |
| Current revision | 現在のリビジョン番号 |
コンテンツタイプを計画したので、データベースの作成に取りかかりましょう。各タイプについて別々のテーブルを作ります。結果として、次のようなテーブルができます:
| テーブル | 説明 |
| Content | コンテンツのアクティブなバージョンと、異なるバージョンで変わらない情報(例:コンテンツの作成者)との関連を保存するため。 |
| Versions | コンテンツの個々のバージョンのデータを保存するため |
| Content types | 私たちのフレームワークのコンテンツタイプを記録し、コンテンツをコンテンツタイプに関連づけます。 |
| Products | 製品に関するデータを拡張します |
| Revision history | 私たちのリビジョンの履歴を保存します |
Content
サイト上のすべてのコンテンツは、このテーブルに保存されます。コンテンツタイプを拡張したい場合は、別のテーブルでそれを行います。例えば製品があるとして、それらは Content テーブルに保存されますが、同時に ID を通じて Products テーブルと関連づけられます。
| フィールド | 型 | 説明 |
| ID | Integer (auto increment) | 他のテーブルとの関連づけ用のフィールド |
| Current_revision | Integer | バージョンテーブルとの関連づけ用のフィールド |
| Active | Boolean | コンテンツが公開済みかどうかを示す |
| Secure | Boolean | コンテンツを認証済みユーザーのみに限定するかどうか |
| Parent | Integer | 親コンテンツとの関連 |
| Order | Integer | コンテンツの並び替え用フィールド |
| Author | Integer | コンテンツを作成したユーザーの ID |
| Type | Integer | コンテンツのデータ拡張のための、コンテンツタイプの ID |
| Path | Varchar | 人間可読 URL を保存するためのフィールド |
これで DB にクエリを実行して Content テーブルを作成できます:
CREATE TABLE `content` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`current_revision` int(11) NOT NULL,
`active` tinyint(1) NOT NULL,
`secure` tinyint(1) NOT NULL,
`parent` int(11) NOT NULL,
`order` int(11) NOT NULL,
`author` int(11) NOT NULL,
`type` int(11) NOT NULL,
`path` char(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;