MariaDB SQL INNER JOIN

 

基本理念

---

關係表和關係型數據庫設計的基本理念。

接下來的內容並未覆蓋以上全部主題，但足夠讓你進入後面的學習。

假設你有一個包含產品類別的數據庫表，每行包含一個類別項。各個類別能夠存儲的信息包括產品介紹和價格，以及生產產品的公司的供應商信息。

由同一個供應商提供的許多不一樣類別的產品，應該把供應商的信息存儲在哪裏？由於以下理由，你不會把供應商信息和產品信息存儲在一塊兒。

1. 由於對於每一個產品，供應商的信息是相同的，對每一個產品重複一樣的信息是在浪費時間和存儲空間。
2. 若是供應商的信息改變，你不得不更新每個存儲的供應商信息。
3. 當數據重複時(即供應商信息和產品信息混合在一塊兒)，每次都以徹底相同的方式輸入數據的機率很低。在報表中沒法使用不一致的數據。

設計關係表時，將信息分割到多個表中，每一個表包含一種數據類型，表與表之間經過相同值聯繫起來 (即關係設計當中「關係」)

以上的🌰例子能夠建立兩個表，一個用來存放供應商信息vendors，另外一個用來存放產品信息products。

vendors表包含供應商的全部信息，表中每行表明一個供應商，而且有一個標識供應商的惟一標誌符。這個值叫作主鍵(primary key)，能夠稱爲供應商id,或者其餘惟一值。

products表僅存儲產品信息，而且除了供應商id以外，沒有供應商其餘的信息。供應商id稱爲外鍵，經過它，關聯venders表盒products表，而且這個供應商id可以讓你經過vendor表找到合適供應商的詳細信息。

外鍵(Foreign Key)在表的一列中包含來自其餘表的主鍵值，這樣就定義了表與表之間的關係。

這樣作的優勢就是：

• 供應商的信息永遠不會重複，所以不會浪費時間和空間
• 若是供應商信息改變了，能夠更新vendors表中的但個記錄。相應表中的數據不會改變
• 因爲沒有重複數據，使用的數據顯然是一致的，這使得數據報表和操做更加簡單

擴展性(Scale)可以隨着數據量的增加進行處理，而不會失敗。一個設計良好的關係型數據庫或者應用程序被稱做擴展性好。

 

建立鏈接

---

 

建立鏈接很是簡單，必須包含全部指定的表，而且說明它們是如何關聯起來的。

SELECT vend_name, prod_name, prod_price FROM vendors, products WHERE vendors.vend_id = products.vend_id
ORDER BY vend_name, prod_name;

 

例子(如下是在不一樣庫裏面的兩張不一樣表):

mysql> select appKeyInfo.appKey, businessId,appName, infoType, appKeyInfo.remark 
from appKeyInfo,crowdRewards.businessInfo 
where appKeyInfo.appKey=businessInfo.appKey and infoType=4 
order by appKeyInfo.id desc 
limit 10;
+------------+------------+---------+----------+-----------------------------------------+
| appKey     | businessId | appName | infoType | remark                                  |
+------------+------------+---------+----------+-----------------------------------------+
| 1194641763 | 133        |         | 4        | zhiyonginfom                            |
| 3217703708 | 132        |         | 4        | 測試使用                            　　  |
| 1029667166 | 0          |         | 4        | sichuanyinyue　　　　　　　　　　　　　　　  |
| 3927050004 | 130        |         | 4        | 546546546                               |
| 1966753355 | 129        |         | 4        | king                                    |
| 2740425196 | 128        |         | 4        | 666663321                               |
| 2496853641 | 127        |         | 4        | 6666633                                 |
| 751377797  | 126        |         | 4        | 66666                                   |
| 1031297745 | 125        |         | 4        | qqqaaa                                  |
| 2061454479 | 124        |         | 4        | qqq                                     |
+------------+------------+---------+----------+-----------------------------------------+
10 rows in set (0.08 sec)

其中，

desc appKeyInfo;

+-----------------+---------------------+------+-----+---------+----------------+
| Field           | Type                | Null | Key | Default | Extra          |
+-----------------+---------------------+------+-----+---------+----------------+
| id              | int(10) unsigned    | NO   | PRI | NULL    | auto_increment |
| appKey          | int(10) unsigned    | NO   | UNI | 0       |                |
| appName         | varchar(32)         | NO   |     |         |                |
| remark          | varchar(32)         | NO   |     |         |                |
| infoType        | tinyint(4) unsigned | NO   |     | 0       |                |
| appLogo         | varchar(128)        | NO   |     |         |                |
+-----------------+---------------------+------+-----+---------+----------------+
6 rows in set (0.06 sec)

desc businessDemo;

+-------------------+------------------------+------+-----+---------+----------------+
| Field             | Type                   | Null | Key | Default | Extra          |
+-------------------+------------------------+------+-----+---------+----------------+
| id                | int(10) unsigned       | NO   | PRI | NULL    | auto_increment |
| name              | varchar(64)            | NO   |     |         |                |
| appKey            | int(10) unsigned       | NO   |     | 0       |                |
| businessID        | int(10) unsigned       | NO   |     | 0       |                |
| remark            | varchar(128)           | NO   |     |         |                |
+-------------------+------------------------+------+-----+---------+----------------+
5 rows in set (0.04 sec)

 

使用WHERE來設置鏈接關係看起來有些奇怪，不過事實上有一個很好的理由支持這種作法。記住，當表經過SELECT語句鏈接起來時，關係的組織是動態。...事實上，你將第一個表中的每一行同第二個表中的每一行進行對比，WHERE事實上就是一個過濾器，使其僅僅包含匹配製定過濾器條件(鏈接條件)的行。沒有WHERE子句，第一個表的每一行將匹配第二個表中的每一行，不管它們是否符合邏輯。

笛卡爾乘積(Cartesian product)沒有使用鏈接條件的表關係的返回結果。返回的行數時第一個表的行數乘以第二個表的行數。

 

不要忘記WHERE子句,確保全部的鏈接都包含WHERE子句，不然MariaDB將返回超出你所需的數據。相似的，確保正確使用WHERE子句，錯誤的過濾條件將會致使MariaDB返回錯誤數據。

交叉鏈接（Cross Joins）這種就是笛卡爾乘積的鏈接類型。

SELECT vend_name, prod_name, prod_price
FROM vendors, products
ORDER BY vend_name, prod_name;

 

內鏈接

---

SELECT vend_name, prod_name, prod_price
FROM vendors INNER JOIN products
ON vendors.vend_id = products.vend_id;

另外，跨庫的鏈接

select dataBaseName1.appKey,dataBaseName2.tableName2.appKey 
from tableName1 inner join dataBaseName2.tableName2
on appKeyInfo.appKey=dataBaseName2.tableName2.appKey;

等值鏈接（equiljoin）一個基於測試兩表相等的鏈接。這種鏈接也被稱做內鏈接。

這裏的兩個表關係被指定爲INNER JOIN.當使用這個語法的時候，鏈接條件使用on來代替where子句，傳遞給on的條件和傳遞給where子句的條件相同。

 

鏈接多個表

---

 

sql沒有明確限制select語句中表鏈接的數量。

建立鏈接的基本規則仍然相同，首先列出全部的表，而後定義表的關係。

SELECT prod_name, vend_name, prod_price, quantity
FROM orderitems, products, vendors
WHERE products.vend_id = vendors.vend_id
    AND orderitems.prod_id = products.prod_id
    AND order_num = 20005;