คำถามติดแท็ก database-design

เรามีสถานการณ์คือเราสามารถ (A) ปรับใช้อินสแตนซ์ของแอปพลิเคชันในฐานข้อมูล MySQL หนึ่งรายการโดยใช้คำนำหน้าตารางหรือ (B) ใช้ฐานข้อมูล MySQL ที่แตกต่างกันสำหรับแต่ละอินสแตนซ์ของแอปพลิเคชันเช่น ตั้งค่า "A": central_database app1_table1 app1_table2 app1_tablen ... appn_table1 appn_table2 appn_tablen ผลลัพธ์ที่ได้คือฐานข้อมูลขนาดใหญ่ที่มีตารางจำนวนมาก ตั้งค่า "B": app1_db table1 table2 tablen ... appn_db table1 table2 tablen ผลลัพธ์ที่ได้คือฐานข้อมูลจำนวนมากที่มีบางตาราง ทุกสิ่งเท่าเทียมกัน (เช่นจำนวนข้อมูลจำนวนอินสแตนซ์ของแอป ฯลฯ ) ข้อดีและข้อเสียของการใช้วิธีการอย่างใดอย่างหนึ่งคืออะไร อะไรจะเป็นอันตรายต่อประสิทธิภาพของฐานข้อมูลและการบำรุงรักษา แอปพลิเคชั่นนี้ใช้ PHP 5 รันบน Apache 2.x และเราใช้ MySQL 5.x ขอบคุณมากสำหรับเวลาและความคิดของคุณ!

14 mysql  database-design 

เรามีตารางที่เราใช้เก็บคำตอบของคำถาม เราจำเป็นต้องสามารถค้นหาผู้ใช้ที่มีคำตอบบางคำถาม ดังนั้นหากตารางของเราประกอบด้วยข้อมูลต่อไปนี้: user_id question_id answer_value Sally 1 Pooch Sally 2 Peach John 1 Pooch John 2 Duke และเราต้องการค้นหาผู้ใช้ที่ตอบว่า 'Pooch' สำหรับคำถามที่ 1 และ 'Peach' สำหรับคำถามที่ 2 SQL จะดังต่อไปนี้ (ชัด) ไม่ต้องกังวล: select user_id from answers where question_id=1 and answer_value = 'Pooch' and question_id=2 and answer_value='Peach' ความคิดแรกของฉันคือการเข้าร่วมโต๊ะด้วยตนเองสำหรับแต่ละคำตอบที่เรากำลังมองหา: select a.user_id from answers a, …

14 mysql  database-design  join 

ฉันกำลังสร้างระบบฐานข้อมูลสำหรับธุรกิจค้าปลีกของฉัน ฉันได้ตั้งค่าบางตารางซึ่ง: สินค้า ซื้อ ขาย สมดุล ทั้งหมดเชื่อมต่อกันและสามารถแสดงระดับสินค้าคงคลังของฉัน ปัญหาที่ฉันมีคือฉันยังขายชุดผลิตภัณฑ์ - ซึ่งมีราคาแตกต่างจากราคาของแต่ละผลิตภัณฑ์ ตัวอย่าง: ฉันขายส้มราคา $ 1, แอปเปิ้ลราคา $ 1.2; ฉันขายแพคเกจผลไม้ 1 (2 ส้มและ 2 แอปเปิ้ล) ในราคา 3.8 ดอลลาร์, แพ็คเกจ 2 (4 ส้มและ 4 แอปเปิ้ล) ในราคา 7 ดอลลาร์ มีวิธีที่ถูกต้องในการสร้างความสัมพันธ์สำหรับกลุ่มผลิตภัณฑ์เหล่านี้หรือไม่ PS: ฉันใช้ FileMaker Pro สร้างสิ่งนี้

14 database-design  relations  filemaker 

เวอร์ชั่นสั้น ฉันต้องเพิ่มคุณสมบัติเพิ่มเติมจำนวนคงที่ให้กับแต่ละคู่ในการเข้าร่วมหลายต่อหลายที่มีอยู่ การข้ามไปยังไดอะแกรมด้านล่างตัวเลือกที่ 1-4 เป็นวิธีที่ดีที่สุดในแง่ของข้อดีและข้อเสียเพื่อให้บรรลุเป้าหมายนี้โดยการขยาย Base Case? หรือมีทางเลือกอื่นที่ดีกว่าที่ฉันไม่ได้พิจารณาที่นี่? รุ่นอีกต่อไป ขณะนี้ฉันมีสองตารางในหลาย ๆ ความสัมพันธ์ผ่านตารางเข้าร่วมระดับกลาง ตอนนี้ฉันต้องเพิ่มลิงก์เพิ่มเติมไปยังคุณสมบัติที่เป็นของคู่ของวัตถุที่มีอยู่ ฉันมีคุณสมบัติเหล่านี้จำนวนคงที่สำหรับแต่ละคู่แม้ว่าหนึ่งรายการในตารางคุณสมบัติอาจนำไปใช้กับหลายคู่ (หรืออาจใช้หลายครั้งสำหรับหนึ่งคู่) ฉันกำลังพยายามหาวิธีที่ดีที่สุดในการทำเช่นนี้และกำลังมีปัญหาในการแยกแยะว่าจะคิดอย่างไรเกี่ยวกับสถานการณ์ ความหมายดูเหมือนว่าฉันสามารถอธิบายเป็นอย่างใดอย่างหนึ่งต่อไปนี้อย่างเท่าเทียมกันดี: คู่หนึ่งคู่เชื่อมโยงกับคุณสมบัติเพิ่มเติมจำนวนหนึ่งชุด หนึ่งคู่เชื่อมโยงกับคุณสมบัติเพิ่มเติมมากมาย วัตถุ (สอง) หลายตัวเชื่อมโยงกับคุณสมบัติหนึ่งชุด วัตถุจำนวนมากเชื่อมโยงกับคุณสมบัติมากมาย ตัวอย่าง ฉันมีประเภทของวัตถุสองชนิดคือ X และ Y แต่ละชนิดมี ID ที่ไม่ซ้ำกันและตารางการเชื่อมโยงที่objx_objyมีคอลัมน์x_idและy_idซึ่งรวมกันเป็นคีย์หลักสำหรับลิงก์ แต่ละ X สามารถเกี่ยวข้องกับ Ys ได้หลายคนและในทางกลับกัน นี่คือการตั้งค่าสำหรับความสัมพันธ์แบบหลายต่อหลายที่มีอยู่ของฉัน เคสฐาน ตอนนี้นอกจากนี้ฉันมีชุดของคุณสมบัติที่กำหนดไว้ในตารางอื่นและชุดของเงื่อนไขที่คู่ (X, Y) ที่กำหนดควรมีคุณสมบัติ P จำนวนเงื่อนไขได้รับการแก้ไขและเหมือนกันสำหรับทุกคู่ พวกเขาพูดว่า "ในสถานการณ์ C1 คู่ (X1, Y1) …

14 relational-theory  database-design 

เป็นวิธีปฏิบัติที่ยอมรับได้หรือไม่ในการใช้ลำดับเดียวเป็นคีย์หลักในทุกตาราง (แทนที่จะเป็นคีย์หลักที่มีลักษณะเฉพาะสำหรับตารางที่กำหนด ถ้าเป็นเช่นนั้นจะเป็นการดีกว่าการใช้ลำดับคีย์หลักเดียวในตาราง ฉันเป็นผู้พัฒนาซอฟต์แวร์รุ่นเยาว์ไม่ใช่ DBA ดังนั้นฉันยังคงเรียนรู้พื้นฐานการออกแบบฐานข้อมูลที่ดีมากมาย แก้ไข: ในกรณีที่มีใครสงสัยฉันเพิ่งอ่านบทวิจารณ์ของการออกแบบฐานข้อมูลโดยหนึ่งใน DBA ของ บริษัท ของเราซึ่งกล่าวว่าเป็นปัญหาที่การออกแบบไม่ได้ใช้คีย์หลักเดียวในฐานข้อมูลทั้งหมดซึ่งฟังดูแตกต่างจากสิ่งที่ ฉันเรียนมาแล้ว แก้ไข 2: เพื่อตอบคำถามในความคิดเห็นนี่สำหรับ Oracle 11g แต่ฉันสงสัยในระดับที่ไม่ใช่ฐานข้อมูล หากคำถามนี้ขึ้นอยู่กับฐานข้อมูลฉันจะสนใจที่จะรู้ว่าทำไม แต่ในกรณีเช่นนี้ฉันจะหาคำตอบเฉพาะสำหรับ Oracle

14 database-design  primary-key 

มีวิธีปฏิบัติที่ดีที่สุดหรือไม่ว่าคีย์ต่างประเทศระหว่างตารางควรเชื่อมโยงกับคีย์ธรรมชาติหรือคีย์ตัวแทน? การสนทนาเดียวที่ฉันพบ (ยกเว้น google-fu ของฉัน) คือคำตอบของแจ็คดักลาสในคำถามนี้และเหตุผลของเขาดูเหมือนจะฟังฉัน ฉันตระหนักถึงการอภิปรายเกินกว่าที่กฎจะเปลี่ยนแปลง แต่นี่จะเป็นสิ่งที่ต้องพิจารณาในทุกสถานการณ์ เหตุผลหลักในการถามคือฉันมีแอปพลิเคชั่นรุ่นเก่าที่ใช้ประโยชน์จาก FKs ด้วยปุ่มธรรมชาติ แต่มีแรงผลักดันจาก devlopers ที่จะย้ายไปยัง OR / M (NHibernate ในกรณีของเรา) และส้อมได้สร้างบางอย่างแล้ว ทำลายการเปลี่ยนแปลงดังนั้นฉันจึงกำลังมองหาที่จะผลักพวกเขากลับมาในการติดตามโดยใช้คีย์ธรรมชาติหรือย้ายแอปรุ่นเก่าเพื่อใช้คีย์ตัวแทนสำหรับ FK ไส้ของฉันบอกว่าจะคืนค่า FK ดั้งเดิม แต่ฉันก็ไม่แน่ใจว่านี่เป็นเส้นทางที่ถูกต้องจริงๆหรือไม่ ตารางส่วนใหญ่ของเรามีทั้งคีย์ตัวแทนและคีย์ธรรมชาติที่กำหนดไว้แล้ว (แม้ว่าจะมีข้อ จำกัด ที่ไม่ซ้ำกันและ PK) ดังนั้นการเพิ่มคอลัมน์เพิ่มเติมจึงไม่ใช่ประเด็นสำหรับเราในเรื่องนี้ เรากำลังใช้ SQL Server 2008 แต่ฉันหวังว่านี่จะเพียงพอสำหรับฐานข้อมูลใด ๆ

14 database-design  foreign-key  surrogate-key  natural-key 

ฉันมีตารางบางส่วนที่ฉันเก็บข้อมูลและขึ้นอยู่กับประเภทของบุคคล (คนงานพลเรือน) ที่ทำงานฉันต้องการเก็บไว้ในeventตารางตอนนี้พวกเหล่านี้ช่วยสัตว์ (มีanimalโต๊ะ) ในที่สุดฉันต้องการโต๊ะเพื่อเก็บเหตุการณ์ที่ผู้ชาย (คนงานพลเรือน) ช่วยชีวิตสัตว์ แต่ฉันควรเพิ่มกุญแจต่างประเทศหรือคำนับให้รู้ถึงidคุณค่าของพลเรือนหรือคนงานที่ทำงานนั้นหรือไม่? ตอนนี้ในการออกแบบนี้ฉันไม่ทราบวิธีการที่เกี่ยวข้องกับคนที่ทำงานถ้าฉันจะมีเพียงคนชนิด (พลเรือนหรือพลเรือน) ฉันจะเก็บcivil_idหุบเขาไว้ในpersonคอลัมน์ในตารางสุดท้ายนี้ แต่วิธีการ รู้ว่ามันเป็นทางแพ่งหรือคนงานฉันต้องการโต๊ะ "กลาง" อื่น ๆ หรือไม่? จะสะท้อนการออกแบบไดอะแกรมต่อไปนี้ใน MySQL ได้อย่างไร? รายละเอียดเพิ่มเติม ฉันสร้างแบบจำลองด้วยวิธีต่อไปนี้: DROP TABLE IF EXISTS `tbl_animal`; CREATE TABLE `tbl_animal` ( id_animal INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(25) NOT NULL DEFAULT "no name", specie VARCHAR(10) NOT NULL DEFAULT …

14 mysql  database-design  subtypes 

ฉันใช้ PostgreSQL แต่ฉันคิดว่าส่วนใหญ่ของฐานข้อมูลบนสุดต้องมีความสามารถที่คล้ายกันและยิ่งไปกว่านั้นโซลูชันสำหรับพวกเขาอาจเป็นแรงบันดาลใจให้ฉันดังนั้นจึงไม่ควรพิจารณาเฉพาะ PostgreSQL นี้ ฉันรู้ว่าฉันไม่ใช่คนแรกที่พยายามแก้ปัญหานี้ดังนั้นฉันคิดว่ามันคุ้มค่าที่จะถามที่นี่ แต่ฉันกำลังพยายามประเมินค่าใช้จ่ายของการสร้างแบบจำลองข้อมูลบัญชีเช่นว่าการทำธุรกรรมทุกครั้งมีความสมดุลทางพื้นฐาน ข้อมูลการบัญชีต่อท้ายเท่านั้น ข้อ จำกัด โดยรวม (เขียนในโค้ดหลอก) ที่นี่อาจมีลักษณะประมาณ: CREATE TABLE journal_entry ( id bigserial not null unique, --artificial candidate key journal_type_id int references journal_type(id), reference text, -- source document identifier, unique per journal date_posted date not null, PRIMARY KEY (journal_type_id, reference) ); CREATE TABLE journal_line …

14 database-design  postgresql  data-integrity 

ฉันกำลังทำงานในโครงการใหม่ที่มีความต้องการใช้ฐานข้อมูล 7 ตัวโดยยืนยันว่าประสิทธิภาพเสถียรภาพการปรับให้เหมาะสมนั้นง่ายขึ้น ในขณะที่ฉันไม่เห็นด้วยฉันมีปัญหาในการรวบรวมอาร์กิวเมนต์ที่ดีเพื่อใช้ฐานข้อมูลเดียว (แยกตารางออกเป็นโดเมนแบบลอจิคัล) อาร์กิวเมนต์หนึ่งที่ฉันมีคือความสมบูรณ์ของข้อมูล (ฉันไม่สามารถใช้คีย์ต่างประเทศระหว่างฐานข้อมูล) ข้อดี / ข้อเสียที่ดีในการใช้ฐานข้อมูลเดียวหรือหลายฐานข้อมูลคืออะไร [สรุปแล้ว] ข้อโต้แย้งกับฐานข้อมูลหลายแห่ง: การสูญเสียความถูกต้องของข้อมูล (ไม่สามารถใช้ foreign key แทนฐานข้อมูล) สูญเสียคืนความสมบูรณ์ การเพิ่มความซับซ้อน (ผู้ใช้ db / บทบาท) เซิร์ฟเวอร์ / ฐานข้อมูลอัตราต่อรองขนาดเล็กจะลดลง Solutions: ใช้สกีมาเพื่อแยกโดเมน POC: ใช้ข้อมูลจำลองเพื่อพิสูจน์จุดในแผนการดำเนินการของ 7/1 db

14 sql-server  sql-server-2008  database-design  architecture 

ฉันต้องใช้ฟังก์ชั่นผู้ใช้ส่วนตัวขั้นพื้นฐานสำหรับเว็บไซต์ของฉัน มีโครงสร้างมาตรฐานสำหรับฐานข้อมูลประเภทนี้หรือไม่? ไลค์มันเป็นเรื่องธรรมดาที่จะมีข้อมูลผู้ใช้และข้อมูลทั้งหมดในตารางเดียวโดยที่ผู้ใช้แต่ละคนมีแถวของตัวเองหรือข้อมูลนี้ควรถูกแบ่งออกเป็นตารางต่าง ๆ และเชื่อมโยงเข้าด้วยกัน (อาจจะมีประสิทธิภาพ?) ณ จุดนี้ แต่เห็นได้ชัดว่าฉันต้องการเข้ารหัสรหัสผ่านไม่นาน ฉันพยายามค้นหาสิ่งที่ฉันกำลังมองหาบน google แต่ไม่มีประโยชน์ เพียงแจ้งให้เราทราบหากคำถามนั้นต้องการคำชี้แจงเพิ่มเติมหรืออะไรก็ตาม

14 database-design 

ฉันได้อ่านคำจำกัดความในhttp://en.wikipedia.org/wiki/Database_engineหลายครั้ง: เอ็นจิ้นฐานข้อมูล (หรือ "หน่วยเก็บเครื่องมือ") เป็นส่วนประกอบซอฟต์แวร์พื้นฐานที่ระบบจัดการฐานข้อมูล (DBMS) ใช้เพื่อสร้างอ่านอัปเดตและลบข้อมูล (CRUD) จากฐานข้อมูล สิ่งที่ฉันไม่เข้าใจคือสิ่งที่เหลือไว้ทำไม่ CRUD ทั้งหมดที่ฐานข้อมูลจะทำอย่างไร หากเอ็นจิ้นฐานข้อมูลทำหน้าที่เหล่านี้ส่วนที่เหลือของฐานข้อมูลจะทำอะไร?

14 architecture  database-engine  database-design 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ฉันต้องการทราบว่าคีย์หลักแบบคอมโพสิตนั้นเป็นแนวปฏิบัติที่ไม่ดีหรือไม่และถ้าไม่แนะนำให้ใช้กับสถานการณ์ใด คำถามของฉันอ้างอิงจากบทความนี้ ส่วนเกี่ยวกับคีย์หลักผสม: การปฏิบัติที่ไม่ถูกต้องหมายเลข 6: คีย์หลักแบบรวม นี่เป็นจุดแย้งเนื่องจากผู้ออกแบบฐานข้อมูลจำนวนมากคุยกันในปัจจุบันเกี่ยวกับการใช้ฟิลด์ที่สร้างโดยอัตโนมัติจำนวนเต็มเป็นคีย์หลักแทนที่จะเป็นคอมโพสิตที่กำหนดโดยการรวมกันของสองฟิลด์หรือมากกว่า ปัจจุบันนี้ถูกกำหนดให้เป็น "แนวปฏิบัติที่ดีที่สุด" และโดยส่วนตัวแล้วฉันมักจะเห็นด้วยกับมัน อย่างไรก็ตามนี่เป็นเพียงการประชุมและแน่นอน DBEs อนุญาตให้นิยามของคีย์หลักแบบผสมซึ่งนักออกแบบหลายคนคิดว่าหลีกเลี่ยงไม่ได้ ดังนั้นเช่นเดียวกับความซ้ำซ้อนคีย์หลักแบบรวมเป็นการตัดสินใจออกแบบ ระวังแม้ว่าหากตารางของคุณที่มีคีย์หลักแบบคอมโพสิตคาดว่าจะมีหลายล้านแถวดัชนีที่ควบคุมคีย์คอมโพสิตสามารถเติบโตขึ้นจนถึงจุดที่ประสิทธิภาพการทำงานของ CRUD ลดลงอย่างมาก ในกรณีนี้จะเป็นการดีกว่ามากหากใช้คีย์หลักจำนวนเต็มแบบง่ายซึ่งดัชนีจะมีขนาดกะทัดรัดเพียงพอและสร้างข้อ จำกัด DBE ที่จำเป็นเพื่อรักษาเอกลักษณ์

14 database-design 

ฉันออกแบบคีมาอีคอมเมิร์ซแรกของฉัน ฉันได้อ่านเรื่องนี้มาระยะหนึ่งแล้วและสับสนเล็กน้อยเกี่ยวกับความสัมพันธ์ระหว่างorder_line_itemกับproduct productสามารถรับการสั่งซื้อ มันมีรายละเอียดที่แตกต่างกัน unit_priceแต่ที่สำคัญที่สุดคือ order_line_itemมีคีย์ต่างประเทศไปproduct_idซื้อที่quantityซื้อและunit_priceที่จุดในเวลาลูกค้าที่ซื้อสินค้า สิ่งที่ฉันได้อ่านส่วนใหญ่บอกว่าควรเพิ่มunit_priceon order_line_item(อย่างชัดเจนโดยไม่อ้างอิงผ่านproduct_id) สมเหตุสมผลเนื่องจากร้านค้าสามารถเปลี่ยนแปลงราคาในอนาคตซึ่งจะทำให้การรายงานคำสั่งซื้อการติดตามความสมบูรณ์และอื่น ๆ สิ่งที่ฉันไม่เข้าใจคือทำไมบันทึกโดยตรงunit_priceไปยังค่าorder_line_itemหรือไม่ การสร้างตารางการตรวจสอบ / ประวัติจะเป็นการดีกว่าการสร้างตารางการunit_priceเปลี่ยนแปลงproductหรือไม่? เมื่อมีการorder_line_itemสร้างคีย์ต่างประเทศของproduct_auditตารางจะถูกเพิ่มและสามารถดึงราคา (โดยอ้างอิง) จากที่นั่น ดูเหมือนว่าฉันจะมีข้อดีหลายอย่างในการใช้วิธีนี้ (การทำซ้ำของข้อมูลน้อยลง, ประวัติการเปลี่ยนแปลงราคาเป็นต้น) ดังนั้นทำไมจึงไม่ใช้บ่อยกว่านี้ ฉันยังไม่เจอตัวอย่างของสคีมาอีคอมเมิร์ซที่ใช้วิธีการนี้ฉันทำอะไรหายหรือเปล่า UDPATE: ดูเหมือนว่าคำถามของฉันที่เกี่ยวข้องกับการเปลี่ยนแปลงอย่างช้าๆมิติ ฉันยังคงสับสนอยู่ว่าในขณะที่การเปลี่ยนมิติช้าเกี่ยวข้องกับคลังข้อมูลและ OLAP ดังนั้นชนิดการเปลี่ยนแปลงมิติช้าสามารถนำไปใช้กับฐานข้อมูลธุรกรรมทางธุรกิจหลักของฉัน (OLTP) ได้หรือไม่ ฉันสงสัยว่าฉันกำลังรวมแนวคิดจำนวนมากเข้าด้วยกันหรือไม่

13 mysql  database-design  schema  audit  data-integrity 

ฉันเจอสถานการณ์ในฐานข้อมูลบ่อยครั้งที่ตารางที่กำหนดสามารถ FK กับหนึ่งในจำนวนของตารางผู้ปกครองที่แตกต่างกัน ฉันเห็นวิธีแก้ไขปัญหาสองข้อ แต่ก็ไม่เป็นที่พอใจ ฉันอยากรู้ว่าคุณเห็นรูปแบบอื่น ๆ ที่นั่นไหม? มีวิธีที่ดีกว่าที่จะทำหรือไม่ contrived ตัวอย่าง ของ Let Alertsบอกว่าระบบของฉันมี สามารถรับการแจ้งเตือนสำหรับวัตถุที่หลากหลาย - ลูกค้าข่าวสารและผลิตภัณฑ์ การแจ้งเตือนที่กำหนดสามารถเป็นแบบหนึ่งเดียวเท่านั้น ไม่ว่าจะด้วยเหตุผลใดก็ตามลูกค้าบทความและผลิตภัณฑ์กำลังเคลื่อนไหวอย่างรวดเร็ว (หรือแปลเป็นภาษาท้องถิ่น) ดังนั้นจึงไม่สามารถดึงข้อความ / ข้อมูลที่จำเป็นลงใน Alerts เมื่อสร้างการแจ้งเตือน ด้วยการตั้งค่านี้ฉันได้เห็นสองวิธี หมายเหตุ: ด้านล่าง DDL สำหรับ SQL Server แต่คำถามของฉันควรใช้กับ DBMS ใด ๆ โซลูชันที่ 1 - FKeys เป็นค่า Nullable หลายตัว ในโซลูชันนี้ตารางที่เชื่อมโยงไปยังตารางหนึ่งในหลายแห่งมีคอลัมน์ FK หลายแห่ง (เพื่อความกะทัดรัดสั้น DDL ด้านล่างจะไม่แสดงการสร้าง FK) …

13 database-design 

ในโครงสร้างฐานข้อมูลของฉันใน SQL Server ฉันมีผลิตภัณฑ์ 3 ประเภทที่ต้องการข้อมูลที่แตกต่างกันเกี่ยวกับการสั่งซื้อ ดังนั้นฉันสร้างหนึ่งของตารางและสามตารางการสั่งซื้อที่แตกต่างกัน:Customers , , ตารางคำสั่งซื้อทั้งหมดมีความสัมพันธ์แบบหนึ่งต่อหลายบนโต๊ะOrdersForProductAsOrdersForProductBsOrdersForProductCsCustomers ฉันยังมีตารางอื่นที่Paymentsจะเก็บรายละเอียดการชำระเงินไว้ข้างใน แต่ฉันมีข้อสงสัยเกี่ยวกับวิธีการจัดโครงสร้างที่นี่ เนื่องจากฉันมีผลิตภัณฑ์หลายประเภทและลูกค้าอาจมีคำสั่งซื้อหลายผลิตภัณฑ์ในเวลาเดียวกันฉันจึงต้องเชื่อมโยงตารางคำสั่งซื้อทั้งสามนั้นเข้ากับPaymentsตาราง ปัญหาอื่นคือลูกค้าอาจมีคำสั่งซื้อผลิตภัณฑ์เพียงประเภทเดียว ดังนั้นคอลัมน์ FK ในตารางจะต้องมีการPaymentsnullable คำถามของฉันคือว่าnullableคอลัมน์ FK เหล่านั้นจะปวดหัวสำหรับฉันในระยะยาวหรือไม่? โดยทั่วไปแล้วจะถือว่าเป็นการปฏิบัติที่ไม่ดีที่จะมีคอลัมน์ FK ที่ไม่มีค่าว่างบนตารางหรือไม่

13 sql-server  sql-server-2008  database-design  sql-server-2008-r2