php spry文本域_《PHP和MySQL Web 开发》第8章 设计Web数据库
封面人物
劉承羽
前言
這是我學習《PHP和MySQL Web 開發》的讀書筆記，一些重要的知識點我會記錄下來，當然只會寫我覺得重要的。
本章主要是介紹了：
- 關系數據庫的概念和術語
- Web數據庫的設計與架構
基礎知識還是要有的，方便了解一些專有名詞，包括數據庫是干啥的，后端說的時候你聽了至少不懵逼。開始吧！
8.1關系數據庫的概念
下方帶灰色底的文字的都是摘錄的書中原文！可放心閱讀，以后不再說明。
當前使用關系數據庫的時候，并不需要了解關系理論（這是一件好事），但還是需要理解一些關于數據庫的基本概念。8.1.1表格
一個表格就是一個數據的表格，就和Excel表格一樣，儲存著數據，就是下面這樣，里面內容不用管，就是讓你看下形式。（一般就叫表）
books +---------------+-------------------+-------------------------------------+-------+ | id | author | title | price | +---------------+-------------------+-------------------------------------+-------+ | 0-672-31697-8 | Michael Morgan | Java 開發 | 38.49 | | 0-672-31745-1 | Thomas Down | Linux 開發 | 27.49 | | 0-672-31509-2 | Pruitt,et al. | 時間管理 | 27.49 | | 0-672-31769-9 | Thomas Schenk | 開放系統管理 | 54.99 | | 0-672-31000-1 | 李重樓 | web開發筆記 | 99.99 | | 0-672-31000-4 | Nicholas C.Zakas | JavaScript高級程序設計(第3版) | 99.99 | | 0-672-31000-5 | 李重樓 | web插入數據庫 | 53.20 | | 0-672-31000-6 | 李重樓 | 網站建設與拆毀 | 44.36 | +---------------+-------------------+-------------------------------------+-------+表名叫books，有id,author,title,price 四個數據列。每個列里對應的是相同的數據類型，每一行對應著是一條由id,author,title,price對應的值構成的數據。
如：0-672-31000-1，李重樓， web開發筆記， 99.99 。這個就是一條數據好理解吧？
注意：豎著的叫列，橫著的叫行。
8.1.2列
表中的每一列都有唯一的名稱，包含不同的數據。此外每一列都有一個相關的數據類型。（注意：豎著的叫列，橫著的叫行。）如上方表格所示，author 列的數據類型就是字符串類型。這個也很好理解吧？具體都有多少數據類型，在后面有介紹，別急，慢慢看。
重點來了！！！
有時候，列也叫做 域 或者 屬性！為啥這是重點？
因為以后開發的時候怎么叫的都有，人家說 列 你腦子里知道是啥，豎著的那豎行叫列，人家說 域 或者說 屬性 你就不知道是啥了那可不行，招人笑話！
也有叫字段的，但是這個一般指 列名字段，比如上面寫的：id,author,title,price 這些。
8.1.3行
表中的每一行代表一個客戶。每一行具有相同的格式，因而也具有相同的屬性。行也稱為記錄。我上面的表格示例表示每一行代表一本書。
具有相同格式是說：第二行的格式和第三行的格式一定相同，好理解吧？其實所有行格式都相同。
重點來了！！！
行也稱為記錄。為啥這是重點？道理剛才說過了。不說了。
8.1.4值
每一行由對應于每一列的單個值組成，每個值必須與改了定義的數據類型相同。這個如果不理解的話，你私信我，我單獨給你解釋。
8.1.5鍵
書里的介紹你先看。
看完了嗎？沒看完不要看下面的筆記。看不下去也要看，讀，一句話一句話的讀。讀完整個8.1.5。
書讀百遍其義自見是有道理的，我也笨，你以為我比你聰明？我有老師教？不！俺沒有，俺讀了三遍，認真的讀了三遍，我就明白了。
有時候你不是學不會，是不認真學，不認真理解，聽我的，感覺一遍沒明白，就再讀一遍。仔細的讀。讀出聲的那種。
看完繼續！
書里整段介紹的提煉的就是一句話：鍵，每一條數據所對應的唯一的標識。
書中舉例說明的是人名，人名不唯一啊！
你回想一下，你，有個朋友說：我認識一個人叫小明。你說：哎呀，巧了，我也認識一個叫小明的。
結果一對，他說的是個女的，你說的是個男的，或者你說的是東北的小明。他說的是臺灣的小明。根本不是一個人。
這就書中舉名字例子要表達的，所以我們需要一系列信息來區分開兩個小明或者確定其中一個你認識的小明，比如：性別，戶籍所在地，出生年月，外加其他的體態外表特征等。
現實生活中：你的身份證號，就是這些信息綜合抽象而成的，就是在這個“社會數據庫”中，人口表中的 鍵，確認你身份的唯一ID。（ID 是identity的縮寫，意思為身份）
這么一想，是不是感覺你家的戶口本其實就很像表？戶口本來有叔叔，阿姨和你，然后戶口表中唯一確定你家三口誰是誰的最快最便捷的身份標識是不是身份證號？
來，再記一遍：鍵，每一條數據所對應的唯一的標識。
表中的標識列稱為 鍵 或 主鍵。這是書中說的，書里說的對，標識列 稱為 鍵 或 主鍵，和你說的有沖突啊？！
不沖突的。
說表的主鍵是什么的時候？
請看上方的books表，上方books表里的id列就是表的主鍵。
為啥id就是主鍵別的不可以嗎？
沒有為啥！！因為我在寫這個表的時候，就遵循的id字段這一列，就是唯一的標識數據，用來做主鍵的。
那你說的，鍵，每一條數據所對應的唯一的標識。是什么意思？
舉例：你找作者叫李重樓的，書名為《網站建設與拆毀 》，44.36一本的書。
這個是不是一條數據？
他的id是 0-672-31000-6 ，這個 0-672-31000-6 就是這一條數據所對應的唯一的標識。
再跟我讀一遍：鍵，每一條數據所對應的唯一的標識。嗯呢，乖~
通常，數據庫由多個表組成，可以使用鍵作為表格之間的引用。這種關系用關系數據庫術語來描述的時候就是外鍵。
這個出現在別的表中的鍵，叫外鍵。
這個看書吧，我覺得很簡單，我實在懶得畫圖了。
8.1.6模式
數據庫整套表格的完整設計成為數據庫的模式。以書中列子來說：Customers(CustomerID,Name,Address,City),這個就是文本格式表示，有的人會手畫表示，怎么都可以，你整明白了就行。我就對這個文本格式的模式進行一下解釋吧。
- Customers：表的名稱，你家的戶口本，戶口本三個字就是表名。
- CustomerID，Name，Address，City 都是表格的列。
- CustomerID 帶下劃線的是的是表示該列是主鍵。
- CustomerID 斜體的表示該列是所在關系表的外鍵。
- CustomerID 又是斜體還有下劃線的表示的是：該列是標識列 叫 主鍵，同時該列是所在關系表的外鍵。
8.1.7關系
這里還是比較復雜難理解，至少我是這么覺得。
所以，如果你覺得很簡單，恭喜你，你是個天才啊~，但是你也覺得難，那么表示確實正常，不要氣餒，老規矩，先讀三遍。
讀完了？
我開始照抄書了啊~
關系數據庫中有3種基本的數據關系類型。根據關系雙方所含對象的多少，可以將這些關系分為 一對一，一對多，多對多3種關系。定義下了，有三種關系。那么開始理解。
一對一關系表示關系雙方只有一個對象相互對應。一對一是好理解的，定義都說了，你只能有一個對象，你對象也只能有一個男/女朋友，而這個男/女朋友得是你。
有一個人好幾個對象的啊？那就是下一步說的了：
在一對多的關系中，一個表中的一行與另一個表中的多行具有相互關聯的關系。這個叫一對多，但是這個不舉男女戀愛的例子了，因為太扎心，咱講父與子的關系。
一個人可以生多個孩子，這些孩子都管這個人叫爹，這個爹就是“一行”，這些孩子就是“多行”，他們的關系是父子關系，如果換成顧客買東西那就是一個顧客可以購買n多件商品他們是購買關系（姑且這么叫吧）。
在多對多的關系中，表中的多行與另一個表中的多行具有相互關聯的關系。這個叫多對多，其實我一開始看的時候在想，什么情況下會出現多對多呢？
現實生活中有什么實際例子能幫我理解消化一下嗎？
我就搜啊搜，看看有啥實際應用的列子嗎？然后我搜到一個很貼近每個人生活，很好的例子：數據表對應關系（一對一、一對多、多對多）。
作者是：Abeam,他個人描述深深的刺激了我，描述是：編程大忌，懶~~~
因為我就懶....
扯遠了。
多對多，在數據庫中也比較常見，可以理解為是一對多和多對一的組合。要實現多對多，一般都需要有一張中間表（也叫關聯表），將兩張表進行關聯，形成多對多的形式。例如： 老師表、班級表、科目表，中間表為：課程表。例子很詳細了，A老師教一二班語文，B老師教一二班數學。你思考一下，教師是個表，表里有AB兩位老師，班級是個表，有一二兩班。
班級表中一班對應兩位老師，A和B。教師表中A對應著兩個班，一班和二班。這個就是多對多，不知道你理解沒有。
暫時沒有理解也沒關系，在后續有實際的應用，會幫助你理解的。
我不得不獻上我的畫作了
自己看圖理解吧。
8.2 設計Web數據庫
本章主要是介紹了：
- 關系數據庫的概念和術語
- Web數據庫的設計與架構
基礎知識還是要有的，方便了解一些專有名詞，包括數據庫是干啥的，后端說的時候你聽了至少不懵逼。開始吧！
書中是以 Book-O-Rama（拉瑪的書店？）的內容為例的，我也盡量吧。
customers +------------+-----------------+--------------------+--------------------+ | customerid | name | address | city | +------------+-----------------+--------------------+--------------------+ | 1 | 劉能 | 牡丹江大街 | 牡丹江 | | 2 | 李重樓 | 北京中弘像素 | 北京 | | 3 | 謝廣坤 | 保定市 | 保定 | | 4 | Alan Wong | 1/47 Haines Avenue | 保定 | | 5 | Michelle Arthur | 357 North Road | Yarraville | | 6 | Melissa Jones | 紅莊 c3-1 | Nar Nar Goon North | +------------+-----------------+--------------------+--------------------+ order +---------+------------+--------+------------+ | orderid | customerid | amount | date | +---------+------------+--------+------------+ | 1 | 3 | 69.98 | 2018-06-27 | | 2 | 1 | 49.99 | 2018-06-26 | | 3 | 2 | 74.98 | 2018-06-25 | | 4 | 3 | 24.99 | 2018-06-24 | +---------+------------+--------+------------+ books +---------------+-------------------+-------------------------------------+-------+ | isbn | author | title | price | +---------------+-------------------+-------------------------------------+-------+ | 0-672-31697-8 | Michael Morgan | Java 開發 | 38.49 | | 0-672-31745-1 | Thomas Down | Linux 開發 | 27.49 | | 0-672-31509-2 | Pruitt,et al. | 時間管理 | 27.49 | | 0-672-31769-9 | Thomas Schenk | 開放系統管理 | 54.99 | | 0-672-31000-1 | 李重樓 | web開發筆記 | 99.99 | | 0-672-31000-4 | Nicholas C.Zakas | JavaScript高級程序設計(第3版) | 99.99 | | 0-672-31000-5 | 李重樓 | web插入數據庫 | 53.20 | | 0-672-31000-6 | 李重樓 | 網站建設與拆毀 | 44.36 | +---------------+-------------------+-------------------------------------+-------+這是我寫的測試數據，后續你寫的時候也可以添加一些自己的數據，很有意思的。目前先看書就可以。
8.2.1考慮要建模的實際對象
當創建一個數據庫時，我們經常為現實世界的實體和關系建立模型，并且儲存這些實體對象與關系的信息。書中這句話就涵蓋了標題的意思。
這一節也沒啥好說的，你保證能理解數據庫表，列，行，字段，值，這些概念，看的懂書中給出圖例的鍵，外鍵就可以。
也別著急實際操作，切勿操之過急。畢竟古人云：捷克，斯洛伐克 嘛。
8.2.2避免保存冗余數據
來，跟我讀：避免保存冗（rǒng ）余數據。（多余的重復或啰嗦內容（包括信息、語言、代碼、結構、服務、軟件、硬件等等）均稱為冗余）
別笑，我之前默念了好幾年的“沉余”，不會，讀錯不丟人，丟人的是 不會，還不學。再讀一遍“ 冗（rǒng ）余”。
這一節開篇沒啥說的做了一下自問自答，你先看吧。
看完咱們來畫重點。
重點來了！！！
三個"不規則"
1.修改不規則
書中舉了Juile在下了訂單后搬家了，需要在三個地方更新她的地址，進行三次同樣的操作。
這很容易使我們在一個地方修改數據，從而導致數據庫中的數據不一致，因為問題發生在修改數據庫的時候所以稱為“修改不規則”。
2.插入不規則
每次必須檢查Juile的數據（地址）是否與表中當前行一致，如果不檢查，可能會有兩行關于Juile相互沖突的數據，比如一條數據告訴我們Juile住二環，另一條則可能表命明她住南四環。
因為出現在插入數據的時候，所以稱之為“插入不規則”。
3.刪除不規則
如果訂單交貨，需要將Juile的訂單信息從數據庫刪除，也意味著她的地址沒有了。她下次再訂貨，還要單獨的提交一遍地址。
因為從數據庫中刪除一行的時候發生的，所以稱之為“刪除不規則”。（這點尤為重要，在電商公司拼命的獲取用戶隱私，地址這么重要的數據，你在用戶收到快遞就給刪了？！這么設計表你能被老大打死！）
通常，數據庫的設計不應該出現上述不規則中的任何一種。書里說的很含蓄，“通常”不這么干。我給你翻譯翻譯就是：除了DEMO 和入門學習！別雞兒這么干！（你們技術老大，或者負責人讓你這么干！你讓他寫下來簽字！）
這里主要是介紹一些數據庫設計的基本原則，業界通用的，所以別煩躁，好好看，萬丈高樓平地起，輝煌還得靠自己！
8.2.3使用原子列值
你看到這的時候，我默認你是看完8.2.3這一節了。
有哪不懂的嗎？
沒有？
太好了！
我有！
使用原子列值得意思是對每一行的每個屬性只儲存一個數據。你給我解釋一下這句話，或者你腦子過一下，這句話什么意思。
如果你能毫不費勁的答出這句話什么意思，我覺得你不應該看我的筆記，因為我覺得沒必要。
如果你一帶而過，沒有深入思考過這句話，或者我問了你，你解釋不上來，那么，不要難過，為啥呃？
因為我第一遍，還沒寫筆記看的時候，也是一帶而過，因為我覺得木有用，不用深入看，不影響我搞后面的內容。
但是！
是誰說的來著？但是之前的話毫無意義！
我要寫筆記給你看的時候，我被這句卡住了！我解釋不上來！
我百度，我谷歌這句話，基本上全是照著書抄！根本沒解釋這句話！
經過我不懈的翻書以及修改關鍵詞，我搜到了！
原文章見此處：一個小時學會MySQL數據庫 ，我截取文章見此處：數據庫規范化。
原文中對MySQL數據庫有概要介紹，包括數據庫的歷史。大致閱讀時間半個小時。
而我呢，截取其中 1.4 部分，用來解釋上面那句話！
所謂第一范式（1NF）是指在關系模型中，對列添加的一個規范要求，所有的列都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。
在符合第一范式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。
簡而言之，第一范式就是無重復的域。
這是其中第一范式的解釋，其中說：原子性，即實體中的某個屬性有多個值時，必須拆分為不同的屬性。對“使用原子列值得意思是對每一行的每個屬性只儲存一個數據”。進行了解釋。
如果不懂去看原文，我都能看懂，你應該也行。還是不懂，私信我。咱倆一起學習！
補充一下：推薦看原文，別嫌棄麻煩！至少我截取的部分 數據庫規范化 要看，多看幾遍，不累的。
所以說，寫閱讀筆記出來，對自己也是一種提高，逼著自己仔細看書，學的扎實~
8.2.4 選擇有意義的鍵
答案：略。
8.2.5考慮需要詢問數據庫的問題
答案：略。
8.2.6 避免多個空屬性的設計
答案：略。
8.2.7避免多個空屬性的設計
答案：略。
上面的 “答案：略” 是不是在初高中參考書里經常見啊？
我是經常見，很煩人，但是那兩節我真的沒有要記得，所以略就略吧。
這三節主要是聯系上下文，傳達基礎理論知識的。多看幾遍沒壞處，我覺得沒必要是因為我記腦子里了~啦啦啦啦
8.3 Web數據庫架構
書里的圖8-9
一個典型的Web數據庫事務包含下列步驟，這些步驟在圖8-9已經標出。以Book-O-Rama書店為例，我們逐個解釋這些步驟。1)用戶的Web瀏覽器發出HTTP請求，請求特定Web頁面。例如，該用戶可能以HTML表單的形式，要求搜索Book-O-Rama書店里所有由Laura Thomson編寫的圖書。搜索結果網頁稱為results.php。
2)Web服務器收到results.php的請求，獲取該文件，并將它傳到PHP引擎，要求它處理。
3)PHP引擎開始解析腳本。腳本中有一條連接數據庫的命令，還有執行一個查詢（執行搜索圖書）的命令。PHP打開通向MySQL數據庫的連接，發送適當的查詢。
4)MySQL服務器接受數據庫查詢并處理。將結果（一個圖書的列表）返回到PHP引擎。
5)PHP引擎完成腳本運行，通常，這包括將查詢結果格式化成HTML格式。然后再將輸出的HTML返到Web服務器。
6)Web服務器將HTML發送到瀏覽器。這樣用戶就可看到她所搜索的圖書。
這個過程基本上與腳本引擎和數據庫服務器無關。通常，Web服務器軟件，PHP引擎和數據庫服務器都在同一臺機器上運行。
但是，數據庫服務器在另外一臺機器上運行也是非常常見的。這樣做是出于保密、提高性能以及負載平衡的原因而考慮的。從開發的角度來看，要做的事情基本上是一樣的，但是它能夠明顯提高性能。
這一節我是純照書敲的，如過你搞過前端開發，應該一看就懂。
不懂就熟讀三遍，學完了整本書你再回來看這段，你就會發現真的沒有什么要說的，啦啦啦啦~
第8章的內容完畢了，其實你要是跟著我這筆記看，包括反復閱讀加理解，時間往寬了說，一天！8個小時~絕對能整明白的，不要怕難~加油哦~看好你哦~
總結
以上是生活随笔為你收集整理的php spry文本域_《PHP和MySQL Web 开发》第8章 设计Web数据库的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面试 jsp转发和重定向
- 下一篇： SQL自定义完整性