在SQL創建一個表，並採取元數據的優勢

功課，要我做一個DB表，該表對應一個百貨公司的一個分支，該表必須包含以下信息：在SQL創建一個表，並採取元數據的優勢

CREATE TABLE STORE 
(

id_store varchar (50), 
name_store varchar (50), 
city varchar (50), 
country varchar (50), 
region varchar (50) 
);

我的問題是我們需要具備城市，國家和地區的字段，還是通過元數據信息，我可以設置一個模式，通過分解主鍵id_state來提供信息。例如前3位數字對應國家，下3位數字對應城市等等。

來源

2011-04-13 franvergara66

您有實際問題。所有的列都是無效的，所以你不能按照定義擁有一個鍵。國名的前三個字母不會產生一個唯一的關鍵字（其他專欄，可探討）;請考慮使用ISO 3166 Alpha-3代碼（http://en.wikipedia.org/wiki/ISO_3166-1_alpha-3）。所有列都是50個字符寬，這是一種'氣味'... – onedaywhen 2011-04-14 08:44:11

您永遠不會想要創建一個系統，其中主鍵嘗試編碼有關該行中其他屬性的數據。這是一個偉大的心痛和痛苦的道路。

它使更新非常困難。例如，如果您決定墨西哥屬於中美洲地區而非北美地區，則您必須通過並更新墨西哥商店的所有主鍵以及系統中每個參考這些主鍵的地方。這是一項巨大的工作，實際上不太可能完成，而且在運行時和測試方面這是非常昂貴的操作。
它使查詢數據變得更加複雜。現在，如果您想查找墨西哥的所有商店，則必須編寫能夠多次調用SUBSTR和INSTR的代碼來解析行所在的國家/地區。對於索引來說，這非常困難，而且優化程序要比單獨的列。確保你沒有代表墨西哥的'墨西哥'，'墨西哥'和'墨西哥'排都很困難。
它違反了正常化的一般原則。城市，國家和地區是商店的獨立識別屬性。應該給他們一個單獨的專欄。

來源

2011-04-13 23:13:31

考慮行業標準密鑰ISBN（http://en.wikipedia.org/wiki/International_Standard_Book_Number），EAN（http://en.wikipedia.org/ wiki/International_Article_Number_（EAN））通過「編碼關於其他屬性的數據」消除了巨大的心痛和痛苦。當然不同的是，這些標識符有機構作爲可信來源。如果一個企業想要爲自己的用途生產這種「智能」密鑰，但可能與OP所提議的方式不同，則可以建立一個類似的可信來源。 – onedaywhen 2011-04-14 08:33:50

@onedaywhen - 我不會使用ISBN作爲主鍵 - 他們已經從10到13位數字的ISBN，所以大多數項目都有。如果您嘗試執行諸如掃描物理項目，獲取一個屬性以及執行數據庫查找以獲取大量其他信息，則這些鍵（ISBN，條形碼等）非常棒。如果您嘗試構建數據模型，那麼它們並不理想。您仍然可以獲得ISBN在數據庫的不同列中編碼的所有信息。 – 2011-04-14 14:01:46

在SQL創建一個表，並採取元數據的優勢

回答

相關問題