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

การพัฒนาสกีมาแนวคิดและ / หรือโมเดลเชิงตรรกะและ / หรือการตั้งค่าทางกายภาพของฐานข้อมูล

1
วิธีการเชื่อมโยงสองแถวในตารางเดียวกัน
ฉันมีตารางที่แถวสามารถเชื่อมโยงซึ่งกันและกันและตามหลักเหตุผลความสัมพันธ์ไปทั้งสองทาง (โดยทั่วไปไม่มีทิศทาง) ระหว่างสองแถว (และหากคุณสงสัยว่าใช่นี่ควรเป็นหนึ่งตารางมันเป็นสองสิ่งที่มีเอนทิตี / ประเภทตรรกะที่เหมือนกัน) ฉันสามารถคิดถึงวิธีที่จะแสดงสิ่งนี้: เก็บความสัมพันธ์และสิ่งที่ตรงกันข้าม จัดเก็บความสัมพันธ์ทางเดียว จำกัด ฐานข้อมูลจากการจัดเก็บในทางอื่นและมีดัชนีสองรายการที่มีคำสั่งตรงกันข้ามสำหรับ FKs (ดัชนีหนึ่งรายการเป็นดัชนี PK) จัดเก็บความสัมพันธ์ทางเดียวด้วยดัชนีสองรายการและอนุญาตให้แทรกสองวิธีต่อไปได้ สร้างตารางการจัดกลุ่มบางประเภทและมี FK ไว้ในตารางต้นฉบับ (เพิ่มคำถามจำนวนมากตารางการจัดกลุ่มจะมีตัวเลขเท่านั้นเพราะเหตุใดถึงมีตารางทำให้ FK NULLable หรือมีกลุ่มที่มีแถวเดียวเชื่อมโยงกัน) อะไรคือข้อดีและข้อเสียที่สำคัญของวิธีการเหล่านี้และแน่นอนมีวิธีที่ฉันไม่เคยคิดบ้างไหม? นี่เป็น SQLFiddle จะเล่นกับ: http://sqlfiddle.com/#!12/7ee1a/1/0 (เกิดขึ้นเป็น PostgreSQL เนื่องจากเป็นสิ่งที่ฉันใช้ แต่ฉันไม่คิดว่าคำถามนี้เฉพาะเจาะจงมากกับ PostgreSQL) ปัจจุบันมีการจัดเก็บทั้งความสัมพันธ์และย้อนกลับเป็นตัวอย่าง

3
โครงสร้างฐานข้อมูล SQL สำหรับ RESTful API
ฉันกำลังสร้าง RESTful API ฉันกำลังดิ้นรนที่จะตัดสินใจเกี่ยวกับวิธีที่ดีที่สุดในการออกแบบตารางฐานข้อมูลรอบทรัพยากรของฉัน ตอนแรกฉันแม้ว่าตารางต่อทรัพยากรจะเป็นวิธีที่ดี แต่ตอนนี้ฉันกังวลว่าสิ่งนี้จะส่งผลให้ตารางมีขนาดใหญ่ขึ้นอย่างทวีคูณยิ่งทำให้ห่วงโซ่ทรัพยากรมากขึ้น ตัวอย่างเช่นสมมติว่าฉันมีทรัพยากรสามอย่างคือผู้ใช้ลูกค้ายอดขาย ผู้ใช้เป็นสมาชิกของ api ของฉันลูกค้าคือลูกค้าผู้ใช้และยอดขายเป็นการซื้อโดยลูกค้าแต่ละรายไปยังบัญชีผู้ใช้ เข้าถึงทรัพยากรการขายดังนี้ GET /users/{userID}/clients/{clientID}/sales/{salesID} ดังนั้นหากมีผู้ใช้ 10 คนแต่ละคนมีลูกค้า 10 คนและสำหรับลูกค้าแต่ละรายมียอดขาย 10 รายการขนาดของตารางจะใหญ่ขึ้นเรื่อย ๆ ตามห่วงโซ่ทรัพยากรที่เราไป ฉันค่อนข้างมั่นใจว่า SQL สามารถรับมือกับตารางขนาดใหญ่ได้ แต่ฉันไม่แน่ใจว่าการอ่านและการเขียนจะทำให้ช้าลงอย่างไร ตัวอย่างข้างต้นอาจไม่ได้อธิบาย แต่ api ของฉันจะมีการเขียนเพิ่มขึ้นและอ่านเพิ่มเติมลงในห่วงโซ่ทรัพยากรที่เราไป ฉันจึงมีสถานการณ์ที่ตารางที่ใหญ่ที่สุดในฐานข้อมูลของฉันจะถูกอ่านและเขียนลงในตารางมากกว่าตารางที่เล็กกว่า นอกจากนี้ยังจำเป็นต้องเข้าร่วมตารางก่อนเรียกใช้แบบสอบถาม เหตุผลก็คือฉันอนุญาตให้ผู้ใช้แต่ละคนมีชื่อลูกค้าเหมือนกัน เพื่อหลีกเลี่ยงการรับข้อมูลไคลเอนต์ที่ไม่ถูกต้องตารางผู้ใช้และตารางไคลเอ็นต์จะถูกรวมโดย {userID} นี่เป็นกรณีขาย การเข้าร่วมตารางขนาดใหญ่และการอ่านและเขียนจะทำให้ช้าลงหรือไม่

4
Supertype / Subtype ตัดสินใจเลือกระหว่างหมวดหมู่: ทำไม่ต่อเนื่องหรือทับซ้อนกันไม่สมบูรณ์
ฉันกำลังสร้างฐานข้อมูลสินค้าคงคลังที่เก็บฮาร์ดแวร์ไอทีเช่นคอมพิวเตอร์เดสก์ท็อปแล็ปท็อปสวิตช์เราเตอร์โทรศัพท์มือถือ ฯลฯ ฉันใช้รูปแบบ supertype / subtype ที่เก็บอุปกรณ์ทั้งหมดไว้ในตารางเดียวและข้อมูลเฉพาะ ใส่ลงในตารางย่อย กระอักกระอ่วนของฉันคือการเลือกระหว่างสองแบบต่อไปนี้: ในแผนภาพด้านบนอุปกรณ์ทั้งหมดแบ่งปันชนิดย่อยทั่วไป ตัวอย่างเช่นคอมพิวเตอร์เดสก์ท็อปและแล็ปท็อปจะมีระเบียนในตารางต่อไปนี้: อุปกรณ์, NetworkDevice สวิตช์จะมีระเบียนเป็น: อุปกรณ์, NetworkDevice เราเตอร์จะมีระเบียนใน: อุปกรณ์, NetworkDevice, WANDevice อุปกรณ์ใด ๆ ที่เราติดตามตำแหน่งจะมีการบันทึกในตำแหน่ง ข้อดีและข้อเสียบางประการที่ฉันคิดไว้สำหรับการตั้งค่านี้: Pro: การเลือกระเบียนตามเขตข้อมูลทั่วไปเช่นชื่อโฮสต์หรือ LocationID นั้นง่ายกว่า Pro: ไม่มีช่องว่าง คอนดิชั่น: ตารางที่ควรรวมอยู่ในการดำเนินการ CRUD สำหรับอุปกรณ์เฉพาะนั้นไม่ชัดเจนและอาจสร้างความสับสนใน DBAs ในอนาคต ในแผนภาพด้านล่างอุปกรณ์ทั้งหมดมีประเภทย่อยของตัวเอง (มีอุปกรณ์มากกว่าคลาสที่ไม่แสดงที่นี่) ในสถานการณ์เช่นนี้จะเห็นได้ชัดว่าระเบียนใดได้รับการแทรกหรือเลือกจากตาราง คอมพิวเตอร์เดสก์ท็อปและแล็ปท็อปไปที่คอมพิวเตอร์ ฯลฯ ข้อดีและข้อเสียบางประการที่ฉันคิดไว้สำหรับการตั้งค่านี้: Pro: เป็นที่ชัดเจนทันทีว่าตารางใดที่จะใช้สำหรับการดำเนินการ CRUD สำหรับชนิดย่อย Pro: ต้องใช้เพียงหนึ่งตารางสำหรับการดำเนินการ CRUD คอนดิชั่น: …

2
บทลงโทษในการใช้คอลัมน์ครอบครัวหรือพื้นที่สำคัญหลายแห่งในคาสซานดราคืออะไร
ฉันอยู่ระหว่างการประเมินการออกแบบที่ดีที่สุดสำหรับการติดตั้ง Cassandra ของเรา มีข้อมูลไม่มากออกมีบนอินเทอร์เน็ตเกี่ยวกับการใช้สองระดับแรกของการเข้าถึงที่คาสซานดรา provides- keyspacesและครอบครัวคอลัมน์ ฉันสงสัยว่าจะได้รับการลงโทษหรือไม่และถ้าคุณเลือกที่จะสร้างคีย์สเปซหรือคอลัมน์ครอบครัวจำนวนมาก (> 10.000) โพสต์บล็อกเก่าบางแห่งแนะนำว่า Cassandra สงวนหน่วยความจำสำหรับแต่ละคอลัมน์ครอบครัว บทความนี้เกี่ยวกับรุ่น 0.6 และรุ่นปัจจุบันคือ 1.0 ยังคงเป็นกรณีนี้และเป็นปัญหาจริงหรือไม่? อะไรคือบทลงโทษของการใช้คอลัมน์ครอบครัวหลายพันคอลัมน์หรือพื้นที่สำคัญในคาสซานดรา

1
การสร้างใบแจ้งหนี้และการติดตาม
ทุก 2 สัปดาห์ระบบจะสร้างใบแจ้งหนี้ให้กับ บริษัท บริษัท จะได้รับใบแจ้งหนี้ในวันที่ 1 และ 16 ของทุกเดือน (มันจะทำงานผ่าน Cron Job ทุก 2 สัปดาห์มันสแกนผ่านตารางคำสั่งซื้อแล้วเพิ่มลงในตาราง 'ใบแจ้งหนี้' มีทางเลือกอื่นหรือไม่) มีรายการคำสั่งซื้อของลูกค้าในordersตารางและยังระบุ บริษัท ที่เป็นของ ( orders.company_id) invoiceตารางการคำนวณค่าใช้จ่ายทั้งหมดของการสั่งซื้อจากordersตาราง ฉันกำลังพยายามหาวิธีการออกแบบการติดตามใบแจ้งหนี้ที่สมเหตุสมผล บริษัท บางครั้งจะต้องส่งค่าธรรมเนียมหรือบางครั้งฉันส่งค่าธรรมเนียม ( invoice.amount) ฉันต้องการติดตามใบแจ้งหนี้ด้วยสิ่งต่อไปนี้: เมื่อ บริษัท ส่งจำนวนเงินให้ฉัน ฉันส่งจำนวนเงินให้ บริษัท เมื่อใด ได้รับเงินจำนวนเท่าใดจาก บริษัท ฉันส่งไปยัง บริษัท เท่าไร ฉันได้รับเงินเต็มจำนวนหรือไม่ (ถ้าไม่ฉันต้องอัปเดตสิ่งใดใน Db) สถานะใบแจ้งหนี้ (ส่งใบแจ้งหนี้, ยกเลิก, จำนวนเงินที่ได้รับ, จำนวนเงินที่ส่ง) นี่คือการออกแบบฐานข้อมูลฉันมาด้วย: …

2
การใช้ schema แยกกันส่งผลต่อประสิทธิภาพของ SQL Server 2008 อย่างไร
ฉันต้องการใช้ schema ที่แยกต่างหากสำหรับวัตถุที่มีวัตถุประสงค์ที่แตกต่างกันในฐานข้อมูล SQL Server 2008 ของเรา ตอนนี้เราใช้หลักการตั้งชื่อที่ทำให้มึนงงอย่างเป็นธรรมเพื่อระบุจุดประสงค์ของตารางหรือขั้นตอนการจัดเก็บและคำนำหน้าหมายความว่าเราต้องสแกนอักขระห้าหรือหกตัวก่อนที่เราจะเห็นจุดเริ่มต้นของชื่อที่ไม่ซ้ำกัน ฉันต้องการใช้สคีมาแยกต่างหากสำหรับตารางที่เพิ่งใช้เพื่อผลักดัน UI (เมนูบทบาทโดยบุคคล ฯลฯ ) และสำหรับผู้ที่เป็นตารางมิติเทียบกับตารางข้อเท็จจริง ฯลฯ คำถามของฉันคือจะมีผลกระทบต่อประสิทธิภาพจากการใช้หลาย schema (schemae?) ตรงข้ามกับ dbo เก่าที่ดีสำหรับทุกสิ่งหรือไม่

3
คอลัมน์“ ชื่อ” เวทมนต์มาจากไหน?
ฉันได้รับสิ่งนี้โดยไม่ได้ตั้งใจ: db=> select name from site; ERROR: column "name" does not exist LINE 1: select name from site; ^ db=> select site.name from site; name --------------- (1,mysitename) (1 row) เคียวรีที่สองส่งคืน tuple ที่มีทั้งแถว ใช้ postgres 9.0.1 แก้ไข: คำจำกัดความของเว็บไซต์ตามคำขอ ฉันไม่สำคัญเลย, เรื่องแปลกประหลาดนี้ใช้ได้กับทุกโต๊ะ db=> \d site Table "public.site" Column | Type | Modifiers --------+---------+--------------------------------------------------- …

2
ฉันจะใช้ฐานข้อมูล / ตารางเป็นกองซ้อนได้อย่างไร
ฉันมีเครื่องรัฐซึ่งจำเป็นต้องผลักดัน / ป๊อปอัพชื่อไฟล์บางอย่างสำหรับผู้ใช้ที่แตกต่างกัน ฉันมักจะใช้สแต็คเป็นทางเลือกของโครงสร้างข้อมูล แต่ต้องทำโดยใช้ฐานข้อมูลเนื่องจากฉันไม่มีวิธีที่จะเก็บโครงสร้างข้อมูลระหว่างการร้องขอเว็บขาเข้า ฉันสงสัยว่าอะไรจะเป็นวิธีที่ดีในการใช้ฟังก์ชันการทำงานของกองซ้อนโดยใช้ฐานข้อมูล ฉันต้องการการสนับสนุน: push (fileName, user): push a fileName สำหรับผู้ใช้ ป๊อป (ผู้ใช้): แสดงชื่อไฟล์ที่ดีที่สุดสำหรับผู้ใช้ แก้ไข : ฉันกำลังสร้างต้นแบบของแนวคิดดังนั้นฉันจึงใช้ sqlite3 กับ python ขอบคุณ!

1
ควรใช้หลายตารางใน DynamoDB เมื่อใด
แนวทางปฏิบัติที่ดีที่สุดของ DyanmoDB ทำให้ชัดเจนว่า: คุณควรดูแลตารางให้น้อยที่สุดเท่าที่จะทำได้ในแอปพลิเคชั่น DynamoDB แอปพลิเคชันที่ออกแบบมาอย่างดีส่วนใหญ่ต้องการเพียงตารางเดียว ฉันพบว่ามันน่าขบขันที่ทุกบทช่วยสอนที่ฉันเห็นเกี่ยวกับ DyanmoDB นั้นมีการออกแบบหลายตาราง แต่สิ่งนี้หมายความว่าในทางปฏิบัติ? ลองพิจารณาแอปพลิเคชันอย่างง่ายที่มีเอนทิตีหลักสามประการ: ผู้ใช้โครงการและเอกสาร ผู้ใช้เป็นเจ้าของหลายโครงการและโครงการสามารถมีเอกสารหลายฉบับ โดยทั่วไปเราจะต้องค้นหาโครงการสำหรับผู้ใช้และเอกสารสำหรับโครงการ อ่านมากกว่าจำนวนที่เขียนโดยระยะขอบที่สำคัญ การออกแบบตารางการสอนที่ไร้เดียงสาจะใช้สามตาราง: Users Hash key user-id Projects Hash key Global Index project-id user-id Documents Hash key Global Index document-id project-id เราสามารถยุบได้ง่ายProjectและDocumentอยู่ในDocumentsตารางเดียว: Documents Hash key Sort key Global Index project-id document-id user-id แต่ทำไมหยุดอยู่ตรงนั้นล่ะ? ทำไมไม่โต๊ะเดียวที่จะปกครองพวกเขาทั้งหมด? เนื่องจากUserเป็นรากของทุกสิ่ง ... Users …

6
ประโยชน์ที่เป็นไปได้ของการจัดเก็บค่าหลายค่าในหนึ่งฟิลด์ของหนึ่งแถวแทนที่จะแยกเป็นแถว
ในระหว่างการประชุมรายสัปดาห์ครั้งล่าสุดของเราบุคคลที่ไม่มีประสบการณ์ด้านการบริหารฐานข้อมูลได้นำคำถามนี้มาใช้: "จะมีสถานการณ์สมมติที่จัดเก็บข้อมูลในบรรทัด (สตริง) แทนที่จะแสดงหลายบรรทัดหรือไม่" ให้เราสมมติตารางcountryStatesที่เราต้องการจัดเก็บสถานะของประเทศ ฉันจะใช้ USA เป็นตัวอย่างนี้และจะไม่แสดงรายการรัฐทั้งหมดเพื่อความเกียจคร้าน ที่นั่นเราจะมีสองคอลัมน์ หนึ่งเรียกว่าCountryและอื่น ๆ Statesที่เรียกว่า ตามที่กล่าวไว้ที่นี่และที่เสนอโดยของ @ srutzky คำตอบที่PKจะได้รับรหัสที่กำหนดโดยมาตรฐาน ISO 3166-1 alpha-3 ตารางของเราจะเป็นดังนี้: +---------+-----------------------+-------------------------------------------------------+ | Country | States | StateName | +---------+-----------------------+-------------------------------------------------------+ | USA | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming | +---------+-----------------------+-------------------------------------------------------+ เมื่อถามคำถามเดียวกันนี้ให้กับนักพัฒนาเพื่อนเขากล่าวว่าจากมุมมองขนาดทราฟฟิกข้อมูลนี่อาจมีประโยชน์ แต่ไม่ใช่ถ้าเราจำเป็นต้องจัดการข้อมูลนี้ ในกรณีนี้จะต้องมีความฉลาดในรหัสแอปพลิเคชันซึ่งสามารถแปลงสตริงนี้ในรายการ …

2
ฉันควรใช้ UUID เช่นเดียวกับ ID
ฉันใช้ UUID ในระบบของฉันมาระยะหนึ่งแล้วด้วยเหตุผลหลายประการตั้งแต่การบันทึกไปจนถึงความสัมพันธ์ที่ล่าช้า รูปแบบที่ฉันใช้เปลี่ยนไปเมื่อฉันไร้เดียงสาน้อยลงจาก: VARCHAR(255) VARCHAR(36) CHAR(36) BINARY(16) เมื่อฉันไปถึงขั้นสุดท้ายBINARY(16)ที่ฉันเริ่มเปรียบเทียบประสิทธิภาพกับจำนวนเต็มพื้นฐานที่เพิ่มขึ้นอัตโนมัติ การทดสอบและผลลัพธ์แสดงไว้ด้านล่าง แต่ถ้าคุณต้องการสรุปก็แสดงว่าINT AUTOINCREMENTและBINARY(16) RANDOMมีประสิทธิภาพเหมือนกันในช่วงข้อมูลสูงสุด 200,000 (ฐานข้อมูลถูกเติมข้อมูลล่วงหน้าก่อนการทดสอบ) ตอนแรกฉันสงสัยว่าจะใช้ UUID เป็นคีย์หลักและแน่นอนฉันก็ยังอยู่ แต่ฉันเห็นศักยภาพที่นี่เพื่อสร้างฐานข้อมูลที่ยืดหยุ่นที่สามารถใช้ทั้งสองได้ ในขณะที่หลายคนเครียดกับข้อได้เปรียบของทั้งสองข้อเสียอะไรที่ถูกยกเลิกโดยการใช้ข้อมูลทั้งสองชนิด? PRIMARY INT UNIQUE BINARY(16) กรณีการใช้งานสำหรับการตั้งค่าประเภทนี้จะเป็นคีย์หลักดั้งเดิมสำหรับความสัมพันธ์ระหว่างตารางโดยมีตัวระบุเฉพาะที่ใช้สำหรับความสัมพันธ์ระหว่างระบบ สิ่งที่ฉันพยายามค้นพบเป็นหลักคือประสิทธิภาพที่แตกต่างระหว่างสองแนวทาง นอกเหนือจากพื้นที่ดิสก์สี่เท่าที่ใช้ซึ่งอาจเล็กน้อยมากหลังจากเพิ่มข้อมูลเพิ่มเติมพวกเขาดูเหมือนจะเหมือนกัน schema: -- phpMyAdmin SQL Dump -- version 4.0.10deb1 -- http://www.phpmyadmin.net -- -- Host: localhost -- Generation Time: Sep 22, 2015 at 10:54 AM …

1
การเพิ่มคอลัมน์แบบ nullable ลงในตารางมีค่าใช้จ่ายมากกว่า 10 นาที
ฉันมีปัญหาในการเพิ่มคอลัมน์ใหม่ในตาราง ฉันพยายามเรียกใช้สองสามครั้ง แต่หลังจากผ่านไปนานกว่า 10 นาทีฉันตัดสินใจยกเลิกคิวรีเนื่องจากเวลาล็อค ALTER TABLE mytable ADD mycolumn VARCHAR(50); ข้อมูลที่เป็นประโยชน์: รุ่น PostgreSQL: 9.1 จำนวนแถว: ~ 250K จำนวนคอลัมน์: 38 จำนวนคอลัมน์ที่ nullable: 32 จำนวนข้อ จำกัด : 5 (1 PK, 3 FK, 1 UNIQUE) จำนวนดัชนี: 1 ประเภทระบบปฏิบัติการ: Debian Squeeze 64 ฉันพบข้อมูลที่น่าสนใจเกี่ยวกับวิธีที่ PostgreSQL จัดการคอลัมน์ที่ไม่มีค่า (ผ่าน HeapTupleHeader) การเดาครั้งแรกของฉันคือเนื่องจากตารางนี้มีคอลัมน์ที่สามารถ nullable ได้ 32 คอลัมน์ซึ่งมี 8 …

3
การใช้ความสัมพันธ์แบบหนึ่งถึงศูนย์หรือหนึ่งความสัมพันธ์ใน SQL
ให้เราบอกว่าฉันกำลังออกแบบฐานข้อมูลสำหรับสถานการณ์ที่มีความสัมพันธ์แบบหนึ่งต่อศูนย์หรือหนึ่ง (1-0..1) ตัวอย่างเช่น: มีชุดของเป็นผู้ใช้และบาง ผู้ใช้ก็อาจจะเป็นลูกค้า ดังนั้นฉันจึงสร้างตารางที่สอดคล้องกันสองตารางusersและcustomersแต่ ... ... วิธีที่ดีที่สุดในการแสดงและนำสถานการณ์นี้ไปใช้ในแพลตฟอร์ม SQL ที่กำหนดคืออะไร ฉันได้พิจารณาวิธีแก้ปัญหาที่เป็นไปได้สองข้อแล้ว: ในusersตารางเพิ่มcustomerคอลัมน์ซึ่งอาจเป็นการอ้างอิงคีย์ต่างประเทศcustomersหรือNULLเครื่องหมาย ในcustomersตารางรวมuserคอลัมน์ (ตั้งค่าด้วยUNIQUEข้อ จำกัด ) ซึ่งชี้ไปที่usersตาราง ฉันได้ถามคำถามที่คล้ายกันในฟอรัมแล้ว แต่คำตอบก็คือ "สิ่งที่คุณต้องการ", "อะไรก็ตามที่คุณคิดว่าสะดวก" ฉันไม่ชอบคำตอบแบบนี้ ฉันต้องการทฤษฎี DB ที่จริงจังแทนคำตอบที่ได้รับการยอมรับอย่างดี ฉันจะอ่านความสัมพันธ์เกี่ยวกับ 1-0..1 ได้ที่ไหน

1
การสร้างข้อ จำกัด ที่ไม่ซ้ำกันในคอลัมน์ Postgres ลบความจำเป็นในการจัดทำดัชนีหรือไม่
การสร้างข้อ จำกัด ที่ไม่ซ้ำกันในคอลัมน์ Postgres ลบความจำเป็นในการจัดทำดัชนีหรือไม่ ฉันคาดหวังว่าดัชนีจำเป็นสำหรับการรักษาข้อ จำกัด ได้อย่างมีประสิทธิภาพโดยอัตโนมัติ

3
การออกแบบสคีมาสำหรับผลิตภัณฑ์ที่มีหลายรูปแบบ / คุณลักษณะ?
ฉันใช้ MySQL แนวคิดนี้คล้ายกับ shopify ด้วยแนวคิดที่แตกต่างกันดังนั้นผู้ใช้จะเพิ่มผลิตภัณฑ์ของตัวเองด้วยตัวแปรและคุณลักษณะหลายประเภท จากการวิจัยทั้งหมดที่ฉันทำไปแล้วดูเหมือนจะเป็นทางออกที่ดีที่สุดสำหรับฉันและฉันแค่สงสัยว่ามีอะไรผิดปกติกับสคีมาดังต่อไปนี้และอัพไซด์ / ข้อเสียคืออะไร? ขอบคุณ Table: products ------------------------------ | ID | ProductName | |----------------------------| | 1 | Leather Wallet Case | | 2 | Jeans | | 3 | Power Bank | Table: products_variants ------------------------------- | ID | ProductId | ParentId | Variant | VariantName | …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.