リレーショナルデータベースのテーブル設計は難しい科学ではありません。これは非常に柔軟なパラダイムであり、アプリケーションの性質に応じて変更される可能性があります。そうは言っても、通常従う必要のある特定の設計原則があります。たとえば、http: //en.wikipedia.org/wiki/Database_designを参照してください。
そうは言っても、アプリケーションの詳細がわからないので、非常に動的に見えるアプローチからこれを試してみます。users
まず、次のようなテーブルが最も確実に必要になります。
ユーザー:
- ファーストネーム
- 苗字
- ユーザーID
- n_tokens
- ユーザーのトークン数が動的である場合に備えて、これをここに配置します
ユーザーを指定する方法ができたので、そのユーザーがトークンをどのように使用したかを確認する必要があります。
トークン:
- token_id
- これは、この(またはこれらの)トークンの使用目的を指定するために使用されます。
- ユーザーID
- これには、users.user_idに重複する外部キー制約が必要です。
- n_tokens
- これはusers.n_tokensとは異なります。機能ごとに常に1つのトークンがあるかどうかは、問題からは明らかではありません。この値は、将来の拡張の可能性についての前向きなアプローチです。
- pagetype_id
- これは、トークンが使用されるページタイプのタイプを指定するためのものです。pagetypes.pagetype_idに外部キー制約があります(以下を参照)。
上記のように、この表で定義されている漫画のページや略歴のページなど、特定のページタイプでトークンを使用してもらいたいと考えています。
ページタイプ:
- pagetype_id
- このタイプのページに一意の識別子を定義するために使用されます
- pagetype_name
- 「漫画」、「バイオ」など、ページタイプにラベルを付ける文字列フィールド。
ここで、ページのタイプを定義する複数のテーブルがある可能性があるため、1つだけのレイアウトを指定します。
bio_pages:
- pagetype_id
- このIDには、pagetypes.pagetype_idに重複する外部キー制約があります。このテーブルの値は常に一定です。より一般的な「ページ」テーブルが必要な場合があるため、これは最も正規化された設計ではありませんが、いくつかの複雑な結合は一部の開発者を混乱させ、さらに悪いことにクエリを遅くする可能性があります。
- token_id
- 他の
- バイオページに属するものを指定したいので、残りのフィールドはユーザー定義です。
まとめ
上記のテーブルレイアウトを要約すると、自己完結型のエンティティが複数のテーブルにまたがらず、複数のエンティティが1つのテーブルに結合されないようにデータベースを設計する必要があります。そうは言っても、私はテーブルを別のテーブルのテーブルから分離しましusers
た。デザインをより直感的にするために、レイアウトの理解に役立つ可能性のあるサンプルクエリをいくつか作成します。tokens
<pagetype>_pages
ユーザーが作成したすべてのバイオページを取得するには:
SELECT bio_pages.*
FROM bio_pages
INNER
JOIN tokens
ON bio_pages.token_id=tokens.token_id
INNER
JOIN users
ON tokens.user_id=users.user_id
WHERE users.first_name='john'
AND users.last_name='doe'
ユーザーが使用したコインの総数と、ユーザーが使用できるコインの最大数を取得するには、次のようにします。
SELECT SUM(tokens.n_tokens) AS used_tokens,
users.n_tokens AS max_tokens
FROM tokens
INNER
JOIN users
ON tokens.user_id=users.user_id
WHERE users.first_name='john'
AND users.last_name='doe'
GROUP BY users.user_id
うまくいけば、これはすべて理にかなっていて、直感的です。不明な点がありましたらお知らせください。