与えられた2つのテーブル:
int id
int operator_id
string name
string description
int price
int id
string logo_path
string tos_path
int tax_number
複数のProduct
を数回呼び出す必要があります。ほとんどの場合、私はProduct
と呼びますが、Operator
の名前とロゴを取得する必要があります。
可能な場合はデータの重複を避け、より洗練された方法でデータをバインドする必要があることはわかっていますが、この場合、int operator_name
とint operator_logo
をProduct
テーブルをリクエストごとに呼び出す代わりに、Operator
を見つけるためのもう1つのリクエスト?
それとも、DBはデータを複製する代わりに、もう1つのリクエストを処理しても問題ないという、本当に関係のポイントですか?
最適化の初心者で、答えを見つけるために何をどこで検索すればよいのかよくわかりません。ありがとうございます。
テーブルが次のように定義されていると仮定しましょう(説明をSQLデータ定義言語-DDLに変換することによって):
CREATE TABLE operator
(
id integer NOT NULL PRIMARY KEY,
logo_path varchar(255),
tos_path varchar(255),
tax_number integer
) ;
CREATE TABLE product
(
id integer NOT NULL PRIMARY KEY,
operator_id integer NOT NULL REFERENCES operator(id), /* This is actually ignored by MySQL, but not by "well-behaved" databases */
name varchar(100),
description varchar(255),
price decimal(12,2)
) ;
いくつかのサンプルデータを入れましょう:
INSERT INTO
operator
(id, logo_path, tos_path, tax_number)
VALUES
(1000, '/path/to/logo/1000', '/path/to/tos/1000', 1234),
(1001, '/path/to/logo/1001', '/path/to/tos/1001', 5678)
;
INSERT INTO
product
(id, operator_id, name, description, price)
VALUES
(1, 1000, 'Product Name', 'Product Description', 1234.56),
(2, 1001, 'Product 2', 'Description 2', 2345.67)
;
...そして今、私たちは SELECT
でJOIN
を実行することができます
SELECT
product.id, product.name, product.price, operator.logo_path,
operator.tos_path, operator.tax_number
FROM
product
JOIN operator ON operator.id = product.operator_id ;
これは、1つのクエリでproduct
とoperator
の両方からデータを取得する場合の結果です。データベースは、テーブルからそれをフェッチする方法を処理します。 リレーショナルデータベースの目的の1つは、データベースにこの種のことを実行させることです
id |名前|価格|ロゴパス| tos_path | tax_number -:| :-------- ------:| :----------------- | :---------------- | ---------: 1 |製品名| 1234.56 |/path/to/logo/1000 |/path/to/tos/1000 | 1234 2 |製品2 | 2345.67 |/path/to/logo/1001 |/path/to/tos/1001 | 5678
dbfiddle ---(hereで遊ぶための完全な例を見ることができます
あなたは常に関係を使いたい、そしてJOIN
、そして繰り返さない。これは正式には データベースの正規化 と呼ばれます
もちろん、すべてのルールには例外がある傾向があります。 非正規化データを持つことは、いくつかの特定のケースに任されています(通常、読み取り専用であり、速度の必要性がある場合最大の懸念事項;これは典型的な データウェアハウス および分析 (OLAP))。
疑わしい場合:正規化します。常に。