主キーSQLチュートリアル–データベースで主キーを定義する方法

Flexportのように、出荷のスタートアップを運営しているとしましょう。ある場所から別の場所に移動する必要のあるパッケージと、それらを輸送する船があります。さらに、これらのパッケージを注文している顧客がいます。

顧客用に1つ、パッケージ用に1つ、輸送用に1つのテーブルが必要であり、現在どのパッケージがどこにあるかを示します。

必要な列と、主キーとなるものを検討してください。あなたがフレックスポートのエンジニアだった場合、これはあなたが理解しなければならない実際の質問です。何も与えられず、すべてが現実の世界で発見されます。

この情報を考慮して、これらのテーブルを次のように設計します。

Customers: first_name, last_name, email, address (for deliveries to their location)
Packages: weight, content
Transportation: <package_primary_key>, Port, time

主キーがありません。さらに読む前にそれらについて考えてください。

パッケージには、代理を選択します PackageID。パッケージのすべての属性（重量、体積、密度、年齢）を一覧表示することもできます。彼らはパッケージを一意に識別しますが、これを実際に行うのは非常に困難です。人々はこれを気にしません、彼らはただある場所から別の場所に移動するパッケージを気にします。

したがって、ランダムな番号を作成し、それをIDとして使用することは理にかなっています。これがまさに、FedEx、UPS、およびすべての配送サービスがバーコードとIDを使用している理由です。これらは、パッケージを追跡するために生成される代理キーです。

お客様には、代理を選択します 顧客ID。ここでも、たとえば、顧客の社会保障番号を選択するオプションがありました。しかし、顧客は私が何かを出荷できるようにするためだけにこれを私と共有することを望んでいません。したがって、内部でキーを生成し、このキーについてお客様に通知せず、引き続きCustomerNoと呼びます。 345681。

おもしろい話：このCustomerNoを公開した企業をいくつか知っていますが、顧客は1位になると主張しました。非常に陽気でした。エンジニアは実際にフロントエンドコードを次のように変更する必要がありました。if (cust == 345681) print(1);

交通機関については、複合を選択します PackageID + Port+time。これはもう少し面白いです。 代理を作成できたはずです ここでも同様に機能します。

しかし、ここにインデックス作成の魔法があります。主キーは自動的にインデックスを取得します。つまり、検索は主キーよりもはるかに効率的です。

このデータベースを検索する場合、ほとんどのクエリは「このパッケージはどこにありますか？」という形式になります。つまり、このPackageIDを指定して、現在のポートと時刻を教えてください。主キーの一部としてPackageIDがない場合は、PackageIDよりも追加のインデックスが必要になります。

これはいいですね。最後のステップとして、これら3つのテーブルをSQLで定義しましょう。構文は、使用しているデータベースによってわずかに異なります。

MySQLでの主キーの定義

CREATE TABLE customers
( customerID  INT(11) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  last_name   VARCHAR(30) NOT NULL,
  first_name  VARCHAR(25) NOT NULL,
  email		  VARCHAR(50) NOT NULL,
  address     VARCHAR(300)
);

CREATE TABLE packages
( packageID  INT(15) NOT NULL AUTO_INCREMENT,
  weight     DECIMAL (10, 2) NOT NULL,
  content    VARCHAR(50),
  CONSTRAINT packages_pk PRIMARY KEY (packageID) # An alternative way to above,
  # when you want to name the constraint as well.
);

CREATE TABLE transportation
( package 	INT(15) NOT NULL,
  port  	INT(15) NOT NULL,
  time	 	DATE NOT NULL,
  
  PRIMARY KEY (package, port, time),
  FOREIGN KEY package
  	REFERENCES packages(packageID)
	ON DELETE RESTRICT    # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.

);

PostgreSQLでの主キーの定義

CREATE TABLE customers
( customerID  SERIAL NOT NULL PRIMARY KEY, # In PostgreSQL SERIAL is same as AUTO_INCREMENT - it adds 1 to every new row.
  last_name   VARCHAR(30) NOT NULL,
  first_name  VARCHAR(25) NOT NULL,
  address     TEXT,
  email		  VARCHAR(50) NOT NULL
);

CREATE TABLE packages
( packageID  SERIAL NOT NULL,
  weight     NUMERIC NOT NULL,
  content    TEXT,
  CONSTRAINT packages_pk PRIMARY KEY (packageID) # In PostgreSQL, this alternative way works too.
);

CREATE TABLE transportation
( package 	INTEGER NOT NULL,
  port  	INT(15) NOT NULL,
  time	 	DATE NOT NULL,
  
  PRIMARY KEY (package, port, time),
  
  FOREIGN KEY package
  	REFERENCES packages(packageID)
	ON DELETE RESTRICT    # It's good practice to define what should happen on deletion. In this case, I don't want things to get deleted.

);

それほど違いはありませんね。基本を理解したら、ドキュメントをざっと見るだけで、ほとんどすべてのデータベースに適用できます。重要なのは、何を探すべきかを知ることです！

頑張って、若いパダワン。

これを楽しんだ？シニアソフトウェアエンジニアから学んだこともお気に召すかもしれません