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

การออกแบบฐานข้อมูลเป็นกระบวนการในการระบุโครงสร้างและด้านตรรกะของฐานข้อมูล เป้าหมายของการออกแบบฐานข้อมูลคือการแสดง "จักรวาลแห่งวาทกรรม" - ประเภทของข้อเท็จจริงกฎเกณฑ์ทางธุรกิจและข้อกำหนดอื่น ๆ ที่ฐานข้อมูลมีวัตถุประสงค์เพื่อเป็นแบบจำลอง

8
การจัดเก็บเพศ (เพศ) ในฐานข้อมูล
ฉันต้องการจัดเก็บเพศของผู้ใช้ในฐานข้อมูลโดยมีต้นทุน (ขนาด / ประสิทธิภาพ) น้อยที่สุด จนถึงตอนนี้มี 3 สถานการณ์อยู่ในใจ Int - สอดคล้องกับ Enum ในรหัส (1 = ชาย, 2 = หญิง, 3 = ... ) ถ่าน (1) - เก็บm , fหรือตัวระบุอักขระเดี่ยวอื่น บิต (บูลีน) - มีชื่อฟิลด์ที่เหมาะสมสำหรับตัวเลือกนี้หรือไม่? เหตุผลที่ฉันถามเป็นเพราะคำตอบนี้ซึ่งระบุว่าตัวอักษรมีขนาดเล็กกว่าบูลีน ฉันควรจะชี้แจงว่าฉันใช้ MS SQL 2008 ซึ่งไมในความเป็นจริงมีประเภทข้อมูลบิต

6
PostgreSQL: ประเภทข้อมูลใดที่ควรใช้สำหรับสกุลเงิน?
ดูเหมือนว่าMoneyประเภทจะหมดกำลังใจตามที่อธิบายไว้ที่นี่ แอปพลิเคชันของฉันต้องการจัดเก็บสกุลเงินฉันจะใช้ประเภทข้อมูลใด ตัวเลขเงินหรือลอย?

4
วิธีสร้างฐานข้อมูลแบบหลายผู้เช่าที่มีโครงสร้างตารางแบบแบ่งใช้
ขณะนี้ซอฟต์แวร์ของเราทำงานบน MySQL ข้อมูลของผู้เช่าทั้งหมดจะถูกเก็บไว้ในสคีมาเดียวกัน เนื่องจากเราใช้ Ruby on Rails เราจึงสามารถระบุได้ว่าข้อมูลใดเป็นของผู้เช่ารายใด อย่างไรก็ตามมี บริษัท บางแห่งที่กลัวว่าข้อมูลของพวกเขาอาจถูกบุกรุกดังนั้นเราจึงประเมินโซลูชั่นอื่น ๆ จนถึงตอนนี้ฉันได้เห็นสามตัวเลือก: หลายฐานข้อมูล (ผู้เช่าแต่ละคนได้รับเป็นของตัวเอง - เกือบเท่ากับ 1 เซิร์ฟเวอร์ต่อลูกค้าหนึ่งราย) Multi-Schema (ไม่มีให้ใน MySQL ผู้เช่าแต่ละคนจะได้รับ schema ของตัวเองในฐานข้อมูลที่แชร์) Shared Schema (แนวทางปัจจุบันของเราอาจมีการระบุบันทึกเพิ่มเติมในแต่ละคอลัมน์) Multi-Schema เป็นรายการโปรดของฉัน (พิจารณาค่าใช้จ่าย) อย่างไรก็ตามการสร้างบัญชีใหม่และการย้ายข้อมูลดูเหมือนจะค่อนข้างเจ็บปวดเพราะฉันจะต้องทำซ้ำกับ schema ทั้งหมดและเปลี่ยนตาราง / คอลัมน์ / คำจำกัดความของพวกเขา ถาม: Multi-Schema ดูเหมือนว่าได้รับการออกแบบให้มีตารางที่แตกต่างกันเล็กน้อยสำหรับผู้เช่าแต่ละคน - ฉันไม่ต้องการสิ่งนี้ มี RDBMS ใดบ้างที่อนุญาตให้ฉันใช้ multi-schema multi-tenant solution ซึ่งมีการแชร์โครงสร้างตารางระหว่างผู้เช่าทั้งหมดหรือไม่ …

11
การออกแบบฐานข้อมูลสำหรับแบบสำรวจ [ปิด]
ปิด . คำถามนี้เป็นคำถามความคิดเห็นตาม ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบได้ด้วยข้อเท็จจริงและการอ้างอิงโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ปรับปรุงคำถามนี้ ฉันต้องการสร้างแบบสำรวจที่เก็บคำตอบไว้ในฐานข้อมูล ฉันแค่สงสัยว่าอะไรคือวิธีที่ดีที่สุดในการนำสิ่งนี้ไปใช้ในฐานข้อมูลโดยเฉพาะตารางที่ต้องการ แบบสำรวจประกอบด้วยคำถามประเภทต่างๆ ตัวอย่างเช่น: ช่องข้อความสำหรับความคิดเห็นคำถามปรนัยและคำถามที่อาจมีมากกว่าหนึ่งคำตอบ (เช่นเลือกทุกข้อที่เกี่ยวข้อง) ฉันคิดวิธีแก้ปัญหาที่เป็นไปได้สองวิธี: สร้างตารางขนาดยักษ์ที่มีคำตอบสำหรับการส่งแบบสำรวจแต่ละครั้ง แต่ละคอลัมน์จะสอดคล้องกับคำตอบจากแบบสำรวจ ได้แก่ SurveyID, Answer1, Answer2, Answer3 ฉันไม่คิดว่านี่เป็นวิธีที่ดีที่สุดเนื่องจากมีคำถามมากมายในแบบสำรวจนี้และดูเหมือนจะไม่ยืดหยุ่นเท่าไหร่หากแบบสำรวจต้องเปลี่ยนแปลง สิ่งอื่นที่ฉันคิดคือการสร้างตารางคำถามและตารางคำตอบ ตารางคำถามจะมีคำถามทั้งหมดสำหรับแบบสำรวจ ตารางคำตอบจะมีคำตอบจากแบบสำรวจแต่ละแถวเชื่อมโยงกับคำถาม ตัวอย่างง่ายๆ: tblSurvey : SurveyID tblQuestion : QuestionID, SurveyID , QuestionType, คำถาม tblAnswer : AnswerID, UserID , รหัสคำถาม , คำตอบ tblUser : UserID, UserName …

15
คีย์หลักหรือดัชนีเฉพาะ?
ในที่ทำงานเรามีฐานข้อมูลขนาดใหญ่ที่มีดัชนีเฉพาะแทนคีย์หลักและทั้งหมดทำงานได้ดี ฉันกำลังออกแบบฐานข้อมูลใหม่สำหรับโปรเจ็กต์ใหม่และฉันมีปัญหา: ในทฤษฎี DB คีย์หลักเป็นองค์ประกอบพื้นฐานก็โอเค แต่ในโครงการ REAL ข้อดีและข้อเสียของทั้งสองอย่างคืออะไร? คุณใช้อะไรในโครงการ? แก้ไข: ... แล้วคีย์หลักและการจำลองแบบบนเซิร์ฟเวอร์ MS SQL ล่ะ?

7
คู่มือเริ่มต้นสำหรับการออกแบบฐานข้อมูล SQL [ปิด]
ปิด. คำถามนี้ไม่เป็นไปตามหลักเกณฑ์กองมากเกิน ขณะนี้ยังไม่ยอมรับคำตอบ ต้องการปรับปรุงคำถามนี้หรือไม่? อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Stack Overflow ปิดให้บริการใน5 ปีที่ผ่านมา ปรับปรุงคำถามนี้ คุณรู้จักแหล่งเรียนรู้วิธีการออกแบบโซลูชัน SQL หรือไม่? นอกเหนือจากไวยากรณ์ภาษาพื้นฐานแล้วฉันกำลังมองหาสิ่งที่จะช่วยให้ฉันเข้าใจ: จะสร้างตารางอะไรและจะเชื่อมโยงอย่างไร วิธีออกแบบสำหรับเครื่องชั่งต่างๆ (แอปไคลเอนต์ขนาดเล็กไปจนถึงเว็บไซต์ขนาดใหญ่) วิธีการเขียนแบบสอบถาม SQL ที่มีประสิทธิภาพ / มีประสิทธิภาพ / สง่างาม

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

2
ใหญ่แค่ไหนสำหรับตาราง PostgreSQL?
ฉันกำลังดำเนินการออกแบบโครงการ RoR สำหรับ บริษัท ของฉันและทีมพัฒนาของเราได้พบกับการถกเถียงกันเล็กน้อยเกี่ยวกับการออกแบบโดยเฉพาะฐานข้อมูล เรามีรูปแบบที่เรียกMessageว่าต้องคงอยู่ เป็นโมเดลขนาดเล็กมากที่มีคอลัมน์ db เพียงสามคอลัมน์นอกเหนือจาก id แต่จะมีโมเดลเหล่านี้จำนวนมากเมื่อเราไปที่การผลิต เรากำลังดูการแทรกมากถึง 1,000,000 ครั้งต่อวัน โมเดลจะถูกค้นหาโดยคีย์ต่างประเทศสองคีย์เท่านั้นซึ่งสามารถจัดทำดัชนีได้ เช่นกันแบบจำลองไม่จำเป็นต้องถูกลบ แต่เราไม่จำเป็นต้องเก็บไว้เมื่อมันมีอายุประมาณสามเดือน ดังนั้นสิ่งที่เราสงสัยคือการใช้ตารางนี้ใน Postgres จะทำให้เกิดปัญหาด้านประสิทธิภาพที่สำคัญหรือไม่? ใครมีประสบการณ์เกี่ยวกับฐานข้อมูล SQL ขนาดใหญ่มากช่วยบอกเราได้หรือไม่ว่าปัญหานี้จะเป็นปัญหา? ถ้าเป็นเช่นนั้นเราควรเลือกทางเลือกใด

16
การออกแบบฐานข้อมูลสำหรับการแก้ไข?
เรามีข้อกำหนดในโครงการที่จะจัดเก็บการแก้ไขทั้งหมด (ประวัติการเปลี่ยนแปลง) สำหรับเอนทิตีในฐานข้อมูล ขณะนี้เรามี 2 ข้อเสนอที่ออกแบบไว้สำหรับสิ่งนี้: เช่นสำหรับนิติบุคคล "พนักงาน" การออกแบบ 1: -- Holds Employee Entity "Employees (EmployeeId, FirstName, LastName, DepartmentId, .., ..)" -- Holds the Employee Revisions in Xml. The RevisionXML will contain -- all data of that particular EmployeeId "EmployeeHistories (EmployeeId, DateModified, RevisionXML)" การออกแบบ 2: -- Holds Employee Entity "Employees …

3
ข้อ จำกัด เฉพาะที่อนุญาตให้มีค่าว่างใน MySQL
ฉันมีฟิลด์ที่เก็บรหัสผลิตภัณฑ์ รหัสไม่ซ้ำกัน แต่ผลิตภัณฑ์บางอย่างไม่มีรหัส ฉันประดิษฐ์รหัสไม่ได้เพราะเป็นรหัสผู้ให้บริการ ข้อ จำกัด แบบนี้เป็นไปได้ไหมใน MySQL ฉันเป็น noob ที่มีขั้นตอนการจัดเก็บและทริกเกอร์ดังนั้นหากการแก้ปัญหาเกี่ยวข้องกับข้อใดข้อหนึ่งโปรดอดใจรอ อัปเดต: คอลัมน์ไม่เป็นโมฆะ นั่นเป็นเหตุผลที่ฉันไม่สามารถทำสิ่งนี้ได้

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

8
ฐานข้อมูล: เพื่อลบหรือไม่ลบบันทึก
ฉันไม่คิดว่าฉันเป็นคนเดียวที่สงสัยเกี่ยวกับเรื่องนี้ โดยปกติคุณปฏิบัติอะไรเกี่ยวกับพฤติกรรมของฐานข้อมูล คุณต้องการลบบันทึกจากฐานข้อมูลทางกายภาพหรือไม่? หรือจะเป็นการดีกว่าที่จะตั้งค่าสถานะระเบียนด้วยแฟล็ก "ลบ" หรือคอลัมน์บูลีนเพื่อแสดงว่าระเบียนนั้นทำงานอยู่หรือไม่มีการใช้งาน

13
วิธีการจัดเก็บรายการในคอลัมน์ของตารางฐานข้อมูล
ดังนั้นจากคำตอบของ Mehrdad สำหรับคำถามที่เกี่ยวข้องฉันเข้าใจว่าคอลัมน์ตารางฐานข้อมูล "ถูกต้อง" ไม่ได้เก็บรายการไว้ แต่คุณควรสร้างตารางอื่นที่เก็บองค์ประกอบของรายการดังกล่าวได้อย่างมีประสิทธิภาพจากนั้นเชื่อมโยงโดยตรงหรือผ่านตารางทางแยก อย่างไรก็ตามประเภทของรายการที่ฉันต้องการสร้างจะประกอบด้วยรายการที่ไม่ซ้ำกัน (ไม่เหมือนกับผลไม้ของคำถามที่เชื่อมโยงตัวอย่าง). นอกจากนี้รายการในรายการของฉันยังถูกจัดเรียงอย่างชัดเจนซึ่งหมายความว่าหากฉันเก็บองค์ประกอบไว้ในตารางอื่นฉันจะต้องจัดเรียงทุกครั้งที่เข้าถึง ในที่สุดรายการก็เป็นแบบปรมาณูเมื่อใดก็ตามที่ฉันต้องการเข้าถึงรายการฉันต้องการเข้าถึงรายการทั้งหมดแทนที่จะเป็นเพียงชิ้นส่วน - ดังนั้นจึงดูเหมือนโง่ที่ต้องออกแบบสอบถามฐานข้อมูลเพื่อรวบรวมชิ้นส่วนของ รายการ. โซลูชันของ AKX (ลิงก์ด้านบน) คือการทำให้รายการเป็นอนุกรมและจัดเก็บไว้ในคอลัมน์ไบนารี แต่สิ่งนี้ก็ดูเหมือนจะไม่สะดวกเช่นกันเพราะหมายความว่าฉันต้องกังวลเกี่ยวกับการทำให้เป็นอนุกรมและการแยกส่วน มีทางออกที่ดีกว่านี้หรือไม่? หากมีคือไม่มีทางออกที่ดีกว่าแล้วทำไม? ดูเหมือนว่าปัญหานี้จะเกิดขึ้นเป็นครั้งคราว ... ข้อมูลเพิ่มเติมเล็กน้อยเพื่อให้คุณรู้ว่าฉันมาจากไหน ทันทีที่ฉันเพิ่งเริ่มทำความเข้าใจ SQL และฐานข้อมูลโดยทั่วไปฉันก็เปิดใช้ LINQ เป็น SQL และตอนนี้ฉันรู้สึกเสียเล็กน้อยเพราะฉันคาดหวังว่าจะจัดการกับโมเดลอ็อบเจ็กต์การเขียนโปรแกรมของฉันโดยไม่ต้องคิดว่าอ็อบเจ็กต์ จะถูกสอบถามหรือเก็บไว้ในฐานข้อมูล ขอบคุณทุกคน! จอห์น อัปเดต: ดังนั้นในคำตอบแรกที่ฉันได้รับคำตอบฉันเห็นว่า "คุณสามารถไปเส้นทาง CSV / XML ได้ ... แต่อย่า!" ตอนนี้ฉันกำลังหาคำอธิบายว่าทำไม ชี้ให้ฉันดูข้อมูลอ้างอิงที่ดี นอกจากนี้เพื่อให้คุณมีความคิดที่ดีขึ้นว่าฉันกำลังทำอะไรอยู่: ในฐานข้อมูลของฉันฉันมีตารางฟังก์ชันที่จะมีรายการคู่ (x, y) (ตารางจะมีข้อมูลอื่น ๆ …

11
Foreign Key ที่เป็นโมฆะปฏิบัติไม่ดี?
สมมติว่าคุณมีตารางคำสั่งซื้อที่มีคีย์ต่างประเทศเป็นรหัสลูกค้า ตอนนี้สมมติว่าคุณต้องการเพิ่มคำสั่งซื้อโดยไม่มีรหัสลูกค้า (คำถามอื่นควรเป็นไปได้หรือไม่) คุณจะต้องทำให้คีย์ต่างประเทศเป็น NULL ... เป็นการปฏิบัติที่ไม่ดีหรือคุณควรใช้ตารางลิงก์ระหว่าง คำสั่งซื้อและลูกค้า? แม้ว่าความสัมพันธ์คือ 1 ถึง n ตารางลิงก์จะทำให้ n ถึง n ในทางกลับกันด้วยตารางลิงค์ฉันไม่มี NULLS อีกต่อไป ... จะไม่มี NULL อยู่ในฐานข้อมูลมากนักเนื่องจากระเบียนที่มี Foreign Key เป็น NULL จะเป็นเพียงชั่วคราวจนกว่าจะมีการเพิ่มลูกค้าสำหรับคำสั่งซื้อ (ในกรณีของฉันไม่ใช่คำสั่งซื้อและลูกค้า) แก้ไข: ลูกค้าที่ยังไม่ได้มอบหมายจะเชื่อมโยงไปถึงอะไร?

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

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