2

私は最初のプロジェクトのためにデータベースにテーブルを設定しているところです。（エキサイティング！）

設定する必要のある関係の種類を決定するのに苦労しています。

以下の基本的なテーブルを計画しています。

products
-----
id
product_name
product_details
product_url
product_img
category_id
business_id


categories
-----
id
category_name
category_description
category_slug


businesses
----------------
id
business_name
business_phone
business_address
business_city
state_id
business_zip

state
-----
id
state_name

私が立ち往生しているのは、どのタイプの関係を設定するかを決めることです。

各商品は1つのカテゴリにのみ属することができ、1つのビジネスにのみ属することができます

ビジネステーブルについては、都市を分割して郵便番号を別々のテーブルに分割する方がよいのではないかと思います。

カテゴリと都市で商品を取得できるようにしたい。たとえば、「ロサンゼルス」の「靴」、「ロサンゼルス」の「靴」またはすべての商品

誰かがいくつかの洞察を提供したり、彼らの経験を共有したりできますか？テーブルを設定する準備ができているので、開発の途中でこれらのシナリオを実行したいと思います。

4

2 に答える 2

3

あなたのデザインは大丈夫です-それはかなりきれいです。多対多はどこにも見当たりません-それはまっすぐな階層のようです。

また、あなたの思考プロセスは明確に見えます-あなた自身にこれらの種類の質問をし続けてください、そしてあなたは大丈夫でしょう。

しかし、私はこれらの提案があります：

まず、テーブルには常にではbusinessなく単数で名前を付けますbusinesses。

次に、テーブル名の前に列名を付けnameないようにbusiness_nameしてください。クエリで参照する場合は、とにかく明らかです:(business.name余分なbusiness_inbusiness.business_nameは冗長です）

また、zipは都市にあり、都市は州にあるため、都市と州をビジネスに保存することは冗長データであるため、おそらく次のようにする必要があります。

business
----------------
id
name
phone
address
zip_code_id

zip_code
--------
id
city_id
name

city
----
id
state_id
name

state
-----
id
name

クエリに関する質問に答えるために、このスキーマで必要なものを取得できます。本当に問題がない限り、ここには投稿しませんが、非常に単純なクエリなので、解決するために残しておきます。

于 2011-07-30T02:02:47.820 に答える
-1

長所と短所を比較検討する必要があります。

多対多の関係では、正規化すると、テーブルが増え、結合が必要になります。これらのレコードを非常に定期的に取得する必要がある場合、結合は非常にコストがかかり、多くのオーバーヘッドが追加されます。

物事を1つの大きなテーブルに入れることにした場合、データの冗長性が増し、ストレージスペースが無駄になりますが、インデックスの使用率が高く、結合がないため、列の組み合わせが常に照会される場合は価値があります。ただし、アプリケーション開発の複雑さが増します。これは特に、非正規化のために異なるテーブルに同じ列があり、両方のテーブルを更新することを覚えておく必要がある場合に当てはまります。これにより、どちらかを更新するのを忘れた場合にデータの不整合のリスクが高まります。

結論は

したがって、実際には状況によって異なります。パフォーマンスが重要であり、複雑さの増大やデータの整合性の問題の可能性を気にしない場合は、非正規化アプローチを採用してください。

ただし、パフォーマンスが大きな問題ではない場合（行数が多くない、ユーザー数が少ない、ハードウェアが十分すぎる、速度が問題にならない）、リレーションシップテーブルを分離すると、ストレージスペースが減少します（最近は非常に安価なので無意味です）。データの整合性を高め、データの不整合を減らし、開発の複雑さを減らします

于 2011-07-30T02:01:44.370 に答える