完美的數據庫設計

-2

低於上午的反饋表格功能模式，請給長好的建議和表及其字段命名的意義，

請分享你對錶模式及其長度和命名約定的建議。

CREATE TABLE `mytest`.`tbl_feedback` (
`feedback_id` INT(30) NOT NULL AUTO_INCREMENT PRIMARY KEY , 
`first_name` VARCHAR(50) NOT NULL , 
`last_name` VARCHAR(50) NOT NULL , 
`email_id` VARCHAR(150) NOT NULL , 
`comment` TEXT NOT NULL , 
`cur_timestamp` VARCHAR(20) NOT NULL , 
`ipaddress` VARCHAR(20) NOT NULL , 
`status` INT(3) NOT NULL DEFAULT '0' 
) ENGINE = MYISAM ;

也是我在這個線程varbinary看到，

在這裏，他們所說的VARCHAR的使用VARBINARY isntead，我們又何必去VARBINARY，有什麼優勢

來源

2011-04-22 vlk

沒有IPv6，呃？太糟糕了。 – Borealid 2011-04-22 03:45:49

這完全取決於您的數據。我們「思考它」是無關緊要的。我唯一能說的是，用'tbl_'前綴表名是多餘的 - 它們都是表格。 – 2011-04-22 03:47:19

@Madmartigan我將tbl_feedback更改爲反饋，將其命名爲反饋反饋，這是很好的建議，人們喜歡哪種方式。 – vlk 2011-04-22 03:51:03

嘗試在可變長度字段之前放置固定長度的字段（例如「狀態」）。這對邏輯沒有任何影響，但程序在訪問這些字段時應該稍微快一些。

來源

2011-04-22 04:11:32

固定長度字段的任何建議，我不明白你能舉一個例子嗎？ – vlk 2011-04-22 06:35:54

狀態是一個整數，所以它是固定的大小。日期，而不是你在這裏有一個，是固定的大小。所有的'varchars'，特別是'comment'字段具有不可預知的長度，這意味着數據庫引擎無法輕易地知道一個元組的結束位置和另一個元素的開始位置。目前我找不到這方面的參考。 – 2011-04-24 14:50:44

某些字段看起來他們的可以被規範化......就像外鍵約束的狀態，狀態表，以及人員作爲一個單獨的表格，人員身份爲FK。然後你可以做一些很酷的事情，比如查看所有人的反饋，或者刪除所有的人等。

來源

2011-04-22 03:47:49

這裏只是一些意見：

表名「tbl_feedback」 - 這是個人喜好，但我會刪除「tbl_」前綴 - 我從來沒有碰到的情況下我發現在數據庫對象上有前綴是很有用的。
email_id - 我將脫掉「_id」後綴。 ID是鍵列（主鍵或外鍵）的常用命名約定，您似乎也在使用該約定。就你而言，它似乎並不像email_id是一個外鍵，所以只是「電子郵件」可能會更好。
cur_timestamp - 像「created_date」或「updated_date」這樣的名稱可能會更有意義。使用cur_timestamp時，不清楚列的內容是什麼，或者當您更新記錄時應該更新它等。另外，對於此列，使用內置類型可能會很有用可以代表一個日期，而不是一個varchar。
ipaddress - 只是一個挑剔，但根據您的命名約定，它可能會更好，如果這是「ip_address」。另外，您可能希望使此列至少有40個字符或更大，以便您可以存儲IPv6地址（使用通用符號）。
status - 此列是否指向另一個「狀態」表？如果是這樣，這是否應該是一個名爲「status_id」的外鍵？

來源

2011-04-22 04:15:15

嗨@Andy White，這裏status_id只是爲了將來的目的，目前的行爲就像旗幟0或1.好吧，我把它作爲狀態。 – vlk 2011-04-22 06:34:19

完美的數據庫設計

回答

相關問題