हाँ, वहाँ सब कुछ ठीक लग रहा है। लेकिन...
कुछ नोट्स:
हम gender . के लिए एक छोटे डेटाटाइप का उपयोग करेंगे कॉलम; मुझे नहीं लगता कि इसे व्यक्त करने के लिए हमें 255 वर्णों की आवश्यकता होगी। (एक पंक्ति के अधिकतम आकार की एक सीमा होती है जिसे लागू किया जाता है।) यदि उसके लिए केवल कुछ मान हैं, तो हम ENUM पर विचार करेंगे। डेटाटाइप।
हम संभावित रूप से NOT NULL भी जोड़ेंगे उन स्तंभों में से कई पर बाधाएं, जैसे कि हेरोनाम, प्रथम नाम, अंतिम नाम। हम संभवतः DEFAULT '' . भी जोड़ेंगे . कभी-कभी, हमें वास्तव में किसी कारण से NULL मानों को अनुमति देने की आवश्यकता होती है, लेकिन हम NOT NULL . का उपयोग करते हैं हम जहां भी कर सकते हैं।
मैं TEXT . के बारे में झिझक रहा हूं स्तंभ। TEXT . का उपयोग करने में कुछ भी गलत नहीं है डेटाटाइप, लेकिन मुझे संदेह है कि वे कुछ ऐसी जानकारी को "छिपा" सकते हैं जिन्हें अतिरिक्त कॉलम में बेहतर तरीके से संग्रहीत किया जा सकता है।
विदेशी कुंजियों के लिए, हम अपने द्वारा उपयोग किए जाने वाले पैटर्न का अनुसरण करते हुए बाधाओं को एक नाम निर्दिष्ट करेंगे, और संभवत:ON UPDATE CASCADE ON DELETE CASCADE भी जोड़ेंगे।
CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
पहचानकर्ताओं के बारे में एक नोट (तालिका नाम और स्तंभ नाम)
जिस तरह से हम इसे करते हैं, सभी टेबल नाम लोअर केस हैं . (हमारे पास एक MySQL विकल्प सेट है जो सभी टेबल नामों को लोअर केस में मजबूर करता है।) हम विभिन्न ऑपरेटिंग सिस्टम/फाइल सिस्टम के लिए असंगतता के मुद्दों से बचने के लिए ऐसा करते हैं (जिनमें से कुछ केस संवेदनशील हैं, और कुछ नहीं हैं)।
साथ ही, तालिका के नाम एकवचन हैं . तालिका का नाम क्या नाम देता है एक पंक्ति तालिका का प्रतिनिधित्व करता है। हम _table . भी शामिल नहीं करते हैं नाम के हिस्से के रूप में।
MySQL में कॉलम नाम कभी भी केस सेंसिटिव नहीं होते हैं, लेकिन हम हमेशा कॉलम नामों के लिए भी लोअर केस का उपयोग करते हैं। हम अपने कॉलम नामों को "CamelCase" नहीं करते हैं, हम विभाजक के रूप में अंडरस्कोर वर्ण का उपयोग करते हैं, उदा। power_id बनाम powerID , hero_name बनाम heroName ।
अनुसरण करें
ऊपर मेरे "नोट्स" विशिष्ट नियम नहीं हैं जिनका पालन किया जाना चाहिए; वे सिर्फ पैटर्न हैं जिनका हम उपयोग करते हैं।
इन पैटर्नों का पालन करने से यह गारंटी नहीं मिलती कि हमारे पास एक सफल सॉफ्टवेयर होगा, लेकिन यह हमारी मदद करता है।
आपके संदर्भ के लिए, मैं दिखाऊंगा कि ये टेबल हमारी दुकान से "फर्स्ट कट" के रूप में कैसे दिखेंगे, दूसरे पैटर्न के उदाहरण के रूप में; यह नहीं है "सही रास्ता", यह सिर्फ "एक तरीका" है जिसे हमने एक टीम के रूप में तय किया है।
CREATE TABLE superhero
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, hero_name VARCHAR(255) NOT NULL COMMENT ''
, first_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, last_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, first_appearance DATE COMMENT 'date superhero first appeared'
, gender ENUM('female','male','other') COMMENT 'female,male or other'
, biography_text TEXT COMMENT ''
, universe VARCHAR(255) COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY superhero_UX1 (hero_name)
) ENGINE=InnoDB;
CREATE TABLE power
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, name VARCHAR(255) NOT NULL COMMENT ''
, description_text TEXT NOT NULL COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY power_UX1 (name)
) ENGINE=InnoDB;
CREATE TABLE superheropower
( superhero_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref superhero'
, power_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref power'
, PRIMARY KEY(superhero_id, power_id)
, CONSTRAINT FK_superheropower_superhero
FOREIGN KEY(superhero_id) REFERENCES superhero(id)
ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT FK_superheropower_power
FOREIGN KEY (power_id) REFERENCES power(id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
