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

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

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

4
คีย์หลัก 5+ คอลัมน์ไม่ดีสำหรับตารางขนาดใหญ่ (100 ล้าน+) หรือไม่
ฉันกำลังอ่านเกี่ยวกับปัญหา DB ของชีวิตจริงและโครงการหนึ่งมี 100 ล้านแถวรวมตารางที่มีคอลัมน์ 5 คอลัมน์เป็นหลัก ฉันคิดว่านี่เป็นสิ่งที่ไม่ดี แต่ทุกคนสามารถบอกฉันได้ว่าทำไม ตารางนั้นเป็นตารางการรวบรวม / การรวมขนาดเล็กดังนั้น 5 คอลัมน์จึงเป็นเช่น (วัน, market_id, product_id ... ) ตอนแรกฉันคิดว่าคีย์หลัก 5 คอลัมน์ไม่เหมาะ แต่ยิ่งฉันคิดฉันก็ไม่สามารถคิดหาเหตุผลที่ดีได้ นี่เป็นการสนทนาช่วงดึกกับวิศวกรของ บริษัท ครึ่งหนึ่ง มีคนพูดถึงเรื่องนี้ว่าเป็นการออกแบบที่ไม่ดีวิศวกรอาวุโสคนหนึ่งเห็นด้วย แต่ก็ไม่มีใครโดดขึ้นไปเลย ดังนั้นพยายามค้นคว้าเรื่องด้วยตัวเอง!

3
CouchDB และเวอร์ชันเอกสาร
ขณะนี้ฉันกำลังทำงานกับแอปพลิเคชัน wiki-esque โดยใช้ CouchDB และฉันกำลังพยายามใช้รูปแบบการกำหนดเวอร์ชันเอกสาร วิธีที่ฉันเห็นมันมีสองวิธีในการทำสิ่งนี้: จัดเก็บแต่ละเวอร์ชันเป็นเอกสารแยกต่างหาก เก็บเวอร์ชันเก่าเป็นสิ่งที่แนบมากับเอกสารฉบับเดียว ตอนนี้ฉันมีรูปแบบการทำงาน # 1 เมื่อผู้ใช้แก้ไขเอกสารและบันทึกไว้แบ็คเอนด์ก่อนจะคัดลอกการแก้ไขก่อนหน้านี้ไปยังเอกสารใหม่จากนั้นบันทึกเวอร์ชันใหม่ แต่ละเอกสารมีอาร์เรย์ 'ประวัติ' ที่มีข้อมูลในแต่ละเวอร์ชัน (เอกสาร _id ของเวอร์ชันเก่าการประทับเวลาตัวแก้ไข ฯลฯ ) เนื่องจากอาร์เรย์ประวัตินี้อาจมีความยาวค่อนข้างมากสำหรับเอกสารที่อัปเดตบ่อยครั้งฉันจึงมีมุมมองที่ดึงข้อมูลประวัติเอกสารในระหว่างการอ่านปกติ (และอีกมุมมองหนึ่งสำหรับดึงข้อมูลประวัติ) คำถามของฉันคือ: ฉันรู้สึกไม่สบายใจเกี่ยวกับวิธีการปัจจุบันของฉันและกำลังคิดที่จะเปลี่ยนเป็นวิธีการ 'แนบ' แต่ฉันไม่แน่ใจ. ฉันหวังว่าคนที่รู้จัก CouchDB ดีกว่าฉัน (ฉันเพิ่งมาที่นี่แค่สองสามสัปดาห์ - และนี่เป็นโครงการแรกของฉันที่ใช้ CouchDB ... และ NoSQL) สามารถบอกได้ว่าข้อดีข้อเสียของแต่ละคน เข้าใกล้ หรืออาจมีโครงร่างเวอร์ชันอื่นที่ฉันมองเห็น

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

2
วิธีออกแบบฐานข้อมูลนี้เพื่อหลีกเลี่ยงการพึ่งพาแบบวนซ้ำ?
มีสองตาราง: ผู้ใช้งาน ที่อยู่ ผู้ใช้มีการอ้างอิงถึงที่อยู่ ที่อยู่มีคอลัมน์ CreatedBy และ ModifiedBy ซึ่งอ้างอิงถึงผู้ใช้ ฉันจะออกแบบฐานข้อมูลนี้เพื่อหลีกเลี่ยงการพึ่งพาแบบวนซ้ำได้อย่างไร

2
การออกแบบฐานข้อมูล SQL Server สำหรับข้อมูล“ เก็บถาวร แต่พร้อมใช้งาน”
เรามีฐานข้อมูลขนาดใหญ่นี้ (> 1TB) ที่เราตั้งใจจะ "ลดขนาด" ฐานข้อมูลหมุนรอบเอนทิตีหลักหนึ่งเรียกว่า "เยี่ยมชม" สำหรับการอภิปรายสมมติว่ามันเป็นฐานข้อมูลสำหรับการปฏิบัติทางการแพทย์ มี "ประเภท" การเข้าชม 30 ครั้งเช่นขั้นตอนรายปีการติดตามการฉีดวัคซีนและอื่น ๆ แต่ละรายการเป็นตารางเงินอุดหนุนสำหรับ "การเยี่ยมชม" เช่น "visit_immuno" ฐานข้อมูลได้สะสมข้อมูล 12 ปีมาตั้งแต่ปี 2000 มีคนเสนอว่าเราเก็บข้อมูลประมาณ 3 ปีในรุ่น "สด" และให้เวลาที่เหลืออยู่ในฐานข้อมูล "old_data" วันที่จะถูกเก็บไว้เฉพาะในตาราง "เยี่ยมชม" เนื่องจากมันถูกทำให้เป็นมาตรฐาน ตารางเยี่ยมชมยังมีROWVERSIONคอลัมน์และคอลัมน์BIGINTหลอก (คลัสเตอร์) สำหรับ intents และวัตถุประสงค์สมมติว่ากุญแจสำคัญในการจัดกลุ่มเป็นประชากรโดยลำดับ (SQL Server 2012 องค์กร) - cidเราจะตั้งชื่อมันว่า คำสั่งvisit.dateนี้ไม่ได้อยู่ในลำดับเดียวกับคีย์การจัดกลุ่มตัวอย่างเช่นเมื่อแพทย์ไปตรวจเยี่ยมเพิ่มเติมและกลับมาพร้อมกับข้อมูล "กระเป๋าเอกสาร" ของเขามันจะถูกรวมเข้าไว้ในตารางหลัก นอกจากนี้ยังมีการปรับปรุงบางอย่างเพื่อ "ไปที่" ตารางที่จะทำให้ROWVERSIONคอลัมน์ที่จะออกจากซิงค์กับทั้งสองcidและdateคอลัมน์ - จะนำมันก็ไม่ROWVERSIONหรือcidจะทำให้คีย์พาร์ทิชันที่เหมาะสมด้วยเหตุผลนี้ …

4
เหตุผลที่ไม่ใช้หมายเลขที่ไม่มีค่าใน Oracle?
บริษัท ของเรากำลังติดต่อกับ บริษัท ซอฟต์แวร์อื่นสำหรับโครงการร่วมกันและเราได้รับแจ้งว่าหากไม่ควรแสดงค่าเฉพาะเราควรผ่านใน -5000 (ค่า Sentinel ตามอำเภอใจ) เหตุผลก็คือไม่มีคอลัมน์ตัวเลขในฐานข้อมูล Oracle ของพวกเขารองรับค่า Null ตามคำแนะนำของ Oracle Dev (ปัจจุบัน) ของพวกเขา บริษัท นี้ยังเขียนโค้ดส่วนใหญ่ของพวกเขาใน VB6 (ค่อยๆเปลี่ยนเป็น VB.NET ซึ่งเป็นอีกหัวข้อหนึ่งสำหรับอีกวันหนึ่ง ... ) จากความอยากรู้อย่างแท้จริงมีเหตุผลใดที่ถูกต้องสำหรับคำแนะนำนี้หรือไม่? ฉันไม่สามารถคิดถึงสิ่งใดในด้านของฉัน --- แก้ไข ขอบคุณสำหรับความคิดเห็นทั้งหมด ฉันโพสต์คำถามเดียวกันบน CodeProject.com ( ลิงก์ ) และได้รับคำติชมที่คล้ายกันมาก ดูเหมือนว่าจะมีเพียงครั้งเดียวที่เราจะสามารถพิสูจน์ได้ว่าการปฏิบัตินี้เกี่ยวข้องกับกุญแจต่างประเทศและฉันสามารถระบุได้ว่าไม่มีกุญแจต่างประเทศใด ๆ ในระบบ นักพัฒนาที่ทำตามข้อตกลงนี้ (ฉันเคยทำงานที่ บริษัท นั้น) มีประสบการณ์มากกว่าฉันอย่างมากดังนั้นฉันจึงต้องการตรวจสอบให้แน่ใจว่าไม่มีเหตุผลที่ถูกต้องสำหรับเรื่องนี้ก่อนที่จะทำการตรวจสอบ

2
ใช้กรณีเดียวกันเมื่อเงื่อนไขสำหรับคอลัมน์แบบสอบถามจำนวนมาก
มีวิธี "ดีกว่า" ในการเขียนSELECTประโยคใหม่ที่มีคอลัมน์จำนวนมากใช้CASE WHENเงื่อนไขเดียวกันเพื่อให้มีการตรวจสอบเงื่อนไขเพียงครั้งเดียวหรือไม่ ดูตัวอย่างด้านล่าง SELECT CASE testStatus WHEN 'A' THEN 'Authorized' WHEN 'C' THEN 'Completed' WHEN 'P' THEN 'In Progress' WHEN 'X' THEN 'Cancelled' END AS Status, CASE testStatus WHEN 'A' THEN authTime WHEN 'C' THEN cmplTime WHEN 'P' THEN strtTime WHEN 'X' THEN cancTime END AS lastEventTime, CASE …

2
บิตกับคอลัมน์บูลีน
เนื่องจากบิตฟิลด์นั้นเป็นเพียงการแสดงข้อมูลแบบไบนารี่และจำเป็นต้องทำการสอบถามในลักษณะที่ "แปลก" เล็กน้อย จริง ๆ แล้วมันให้ประโยชน์ใด ๆ โดยใช้เขตข้อมูลบิตสำหรับค่าบูลีนหรือไม่ จากสิ่งที่ฉันเห็นมันดูเหมือนว่าจะแนะนำว่าพื้นที่นั้นเป็นผลประโยชน์ที่แท้จริงเท่านั้น

5
การออกแบบฐานข้อมูลแบบสำรวจ: เชื่อมโยงคำตอบกับผู้ใช้
ฉันทำแบบจำลองแนวคิดสำหรับฐานข้อมูลการสำรวจ เป้าหมายคือเก็บคำตอบที่ได้รับจากผู้ใช้ (มันจะเป็นแอพ Android) ฉันมีสามเอนทิตี: ผู้ใช้คำถามและตัวเลือก คำถามจะมีหนึ่งหรือมากกว่าหนึ่งตัวเลือก (ตัวอย่างเช่น: คุณมีพนักงานกี่คนมี? 1-40, 40-1000, 1000) ตัวเลือกจะมีข้อความ (1-40) และค่า (ค่าที่เลือกโดยผู้ใช้) ผู้ใช้จะเลือกหนึ่งตัวเลือก (หรือมากกว่า) ของตัวเลือกเหล่านี้ แนวคิดการออกแบบของฉันคือ: ฉันไม่ทราบวิธีเชื่อมโยงคำตอบกับผู้ใช้ ฉันจะแสดงความสัมพันธ์นั้นได้อย่างไร ฉันมีเอนทิตีอื่นเพื่อแทนค่าตัวเลือกหรือไม่ รุ่นนี้จะเก็บคำถามและคำตอบล่วงหน้า (คำตอบที่เสนอ) และอนุญาตให้ใช้ซ้ำในแบบสำรวจต่างๆ ฉันต้องแสดงคำถามเช่นนี้: คำถามนี้เกี่ยวข้องกับคำถามนี้: การออกแบบฐานข้อมูลแบบสำรวจ: เวอร์ชันแรก มีข้อผิดพลาดหรือไม่?

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

2
พารามิเตอร์โพรซีเดอร์ที่เก็บมีจำนวนมากเกินไป?
ฉันเพิ่งเริ่มเขียนกระบวนงานที่เก็บไว้ใน SQL Server 2008 และมีพารามิเตอร์มากกว่า 30 รายการ ฉันไม่เคยเขียนหนึ่งที่มีมากกว่า 10 พารามิเตอร์และนั่นทำให้ฉันคิดว่า ... ณ จุดใดมีพารามิเตอร์มากเกินไป? สำหรับบริบท ... ขั้นตอนนี้จะต้องแทรกแถวเดียวลงในตารางเดียว ก็จะมีความคล้ายคลึงกันมาก แม้ว่าจะค่อนข้างเล็ก เวอร์ชันที่ดำเนินการUPDATEบนตารางเดียวกัน คอลัมน์ส่วนใหญ่มีขนาดค่อนข้างเล็กโดยมีการผสมผสานของ int และ strings ( varchar(200)) ปัญหาคืออะไร; ดีหรือไม่ดี การมีโพรซีเดอร์ที่มีพารามิเตอร์จำนวนมากและเกณฑ์ที่ฉันควรเริ่มพิจารณารูปแบบอื่นคืออะไร

2
เทคนิคที่เหมาะสมสำหรับการจัดเก็บข้อมูลเหตุการณ์ของผู้ใช้
ฉันส่วนใหญ่เรียนรู้ด้วยตนเองเมื่อพูดถึงการออกแบบฐานข้อมูล ฉันโพสคำถามนี้เพราะฉันได้ตัดสินในโครงสร้างทั่วไปนี้ แต่ฉันสงสัยว่ามันเป็นวิธีที่มีประสิทธิภาพมากที่สุดหรือ 'มาตรฐานอุตสาหกรรม' ฐานข้อมูลส่วนใหญ่ที่ฉันออกแบบมีตารางผู้ใช้แล้วมีการติดตามบุคคล activty ในตารางอื่น ฉันเข้าใจว่าความสวยงามของฐานข้อมูลคือการมีประสิทธิภาพเหล่านี้ แต่ตารางกิจกรรมจะรวบรวมเหตุการณ์จำนวนมากอย่างรวดเร็วจากผู้ใช้ทุกคนที่ใช้เป็นประจำอย่างรวดเร็วซึ่งจะกลายเป็นตารางขนาดใหญ่อย่างรวดเร็วด้วยการใช้ผู้ใช้ในระดับปานกลาง นี่เป็นวิธีที่ดีที่สุดที่จะปล่อยให้มันเติบโตในลักษณะนี้หรือไม่? หรือเป็นระดับของตารางหรือแยกไปตามตารางที่แตกต่างกันตามวันที่หรือต่อจำนวนผู้ใช้หรืออย่างอื่น +--------------------+ +------------------------+ | UserData | | Activity | +-=------------------+ +------------------------+ | ID (auto uint) | <--1-to-many-+ | ID (auto uint) | | UserName (text) | +--> | UserID (uint) | | Email (text) | | Timestamp (time) | | …

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

3
วิธีการนำเอนทิตีไปใช้ด้วยจำนวนแอตทริบิวต์สูงสุดที่ไม่รู้จัก?
ฉันกำลังออกแบบโปรแกรมจำลองเบสบอลและฉันพบปัญหาในการออกแบบสคีบ็อกซ์ ปัญหาที่ฉันมีคือฉันต้องการติดตามจำนวนการทำคะแนนในแต่ละโอกาส วิธีที่ฉันทำในโปรแกรมจริงคือการใช้อาร์เรย์แบบไดนามิกที่เพิ่มขึ้นสำหรับการเล่นแต่ละโอกาส สำหรับผู้ที่ไม่คุ้นเคยกับเกมเบสบอลเกมมักจะมีเก้าโอกาสนานเว้นแต่เกมจะถูกผูกไว้เมื่อสิ้นสุดโอกาสที่ 9 เกมเบสบอลจึงมีความยาวไม่บึกบึนซึ่งหมายความว่าฉันไม่สามารถออกแบบฐานข้อมูลให้มีเพียง 9 คอลัมน์สำหรับการวิ่งที่ทำคะแนนในแต่ละโอกาส (ในทางเทคนิค 18 (9-9 อินนิ่ง * 2 ทีม) แนวคิดหนึ่งที่ฉันมีคือทำให้อนุกรมอาร์เรย์ และเข้ารหัสเป็น Base64 ก่อนเก็บไว้ในฐานข้อมูลอย่างไรก็ตามฉันไม่รู้ว่านี่เป็นเทคนิคที่ดีในการใช้หรือไม่และฉันสงสัยว่าใครมีความคิดที่ดีกว่า ในกรณีที่มีความสำคัญฐานข้อมูลที่ฉันกำลังพัฒนาคือ PostgreSQL ข้อเสนอแนะใด ๆ ที่ชื่นชมอย่างมาก! ขอบคุณ!

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