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

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


4
การออกแบบฐานข้อมูลการบันทึกรายการสองครั้ง
ฉันกำลังสร้างซอฟต์แวร์บัญชี ฉันต้องบังคับใช้การบันทึกบัญชีสองครั้ง ฉันมีปัญหาคลาสสิกของหนึ่งแถวต่อการทำธุรกรรมเทียบกับสองแถว ลองมาเป็นตัวอย่างและดูว่าจะมีการนำไปใช้อย่างไรในทั้งสองสถานการณ์ พิจารณาบัญชีและบัญชีCash Rentเมื่อฉันจ่ายค่าเช่ารายเดือนฉันจะโอน $ 100 จากCashบัญชีของฉันไปยังRentบัญชีของฉัน หนึ่งแถวต่อธุรกรรม ในระบบแถวเดียวธุรกรรมดังกล่าวจะถูกจัดเก็บเป็น: การทำธุรกรรม tx_id | posting_date 1 | 23/05/2015 transaction_records id | tx_id | credit_account | debit_account | amount 1 | 1 | Cash | Rent | 100.00 สองแถวต่อธุรกรรม ในระบบสองแถวฉันจะต้องทำรายการบันทึกเดียวกันเพื่อสร้างระเบียนตรงกันข้ามที่เมื่อฉันสรุปผลรวมทั้งสองฉันจะได้ยอดเงินเป็นศูนย์ การทำธุรกรรม tx_id | posting_date 1 | 23/05/2015 transaction_records id | tx_id …

6
ต้องการหนังสือออกแบบฐานข้อมูล [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัพเดตคำถามเพื่อให้เป็นไปตามหัวข้อสำหรับ Exchange Administrators Stack Exchange ปิดเมื่อปีที่แล้ว ล็อคแล้ว คำถามและคำตอบนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันกำลังออกแบบฐานข้อมูลและมีความสัมพันธ์มากมายระหว่างตารางของฉันและฉันต้องการหนังสือที่สอนการออกแบบฐานข้อมูลได้เป็นอย่างดีฉันกำลังมองหาหนังสือที่ความสัมพันธ์ของตารางเรียบง่ายและซับซ้อนได้รับการครอบคลุมอย่างกว้างขวางและอาจเป็นกรณีศึกษาในหนังสือ

2
ใช้ข้อความสูงสุด MAX หรือเฉพาะเจาะจงน้อยกว่านั้น
มีคนถูกตรวจสอบรหัส DDL ของการสร้างตารางและแนะนำเมื่อพวกเขาเห็นผมเห็นโดยใช้VARCHAR(256)ฟิลด์สำหรับข้อความที่ผมคาดหวังว่าจะสวยขนาดเล็กเหมือนชื่อหรือสิ่งที่ฉันควรจะเสมอเพียงแค่ใช้VARCHAR(MAX)และเชื่อมโยงทำไมต้องใช้อะไร แต่ (สูงสุด varchar ) . ฉันอ่านมัน แต่ดูเหมือนว่ามันล้าสมัยเพราะมันมุ่งเน้นไปที่ปี 2005 และดูเหมือนจะไม่ได้เสนอเหตุผลที่แท้จริงในการจัดสรรที่อาจเกิดขึ้นถึง 2 GB ต่อแถวในเขตข้อมูลข้อความทั้งหมด จากมุมมองด้านประสิทธิภาพการจัดเก็บและอื่น ๆ เราควรตัดสินใจอย่างไรว่าจะใช้งานVARCHAR(MAX)หรือใช้SQL Server รุ่นใหม่ที่มีขนาดเฉพาะเจาะจงน้อยลง (เช่น 2008, 2012, 2014)

3
จะมีความสัมพันธ์แบบตัวต่อตัวกับเด็กที่มีสิทธิพิเศษอย่างไร
ฉันต้องการที่จะมีความสัมพันธ์แบบหนึ่งต่อหลายคนซึ่งสำหรับผู้ปกครองแต่ละคนเด็กหนึ่งหรือศูนย์ถูกทำเครื่องหมายเป็น "รายการโปรด" อย่างไรก็ตามผู้ปกครองทุกคนจะไม่มีลูก (นึกถึงผู้ปกครองว่าเป็นคำถามในไซต์นี้เด็ก ๆ เป็นคำตอบและชอบเป็นคำตอบที่ยอมรับ) ตัวอย่างเช่น TableA Id INT PRIMARY KEY TableB Id INT PRIMARY KEY Parent INT NOT NULL FOREIGN KEY REFERENCES TableA.Id วิธีที่ฉันเห็นฉันสามารถเพิ่มคอลัมน์ต่อไปนี้ใน TableA: FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id หรือคอลัมน์ต่อไปนี้เพื่อ TableB: IsFavorite BIT NOT NULL ปัญหาเกี่ยวกับวิธีแรกคือมันแนะนำคีย์ต่างประเทศที่ไม่มีค่าซึ่งฉันเข้าใจว่าไม่ได้อยู่ในรูปแบบปกติ ปัญหาเกี่ยวกับแนวทางที่สองคือต้องทำงานมากกว่านี้เพื่อให้แน่ใจว่าเด็กส่วนใหญ่จะเป็นคนโปรด เกณฑ์ประเภทใดที่ฉันควรใช้เพื่อกำหนดวิธีการที่จะใช้ หรือมีวิธีอื่นที่ฉันไม่ได้พิจารณาหรือไม่? ฉันใช้ SQL Server 2012

3
วิธีเลือกการเปรียบเทียบสำหรับฐานข้อมูลสากล?
ฉันกำลังออกแบบฐานข้อมูลที่จะเก็บข้อมูลในภาษาต่าง ๆ (โดยใช้ UTF-8) ดังนั้นฉันคิดว่าวิธีที่ดีที่สุดในการแสดงผลลัพธ์ของแบบสอบถามคือการสั่งซื้อตามภาษาของผู้ใช้ในระหว่างการสืบค้น ( เพราะมีมากกว่าหนึ่ง วิธีที่ถูกต้องในการทำเช่นนั้น ) ดังนี้: SELECT a < b COLLATE "de_DE" FROM test1; สมมติว่านี่เป็นวิธีที่ถูกต้องในการทำงานกับข้อมูลระหว่างประเทศซึ่งเป็นการเปรียบเทียบที่ดีที่สุดสำหรับฐานข้อมูลตัวเอง? เอกสาร PostgreSQL บอกว่า : การเปรียบเทียบทั้ง C และ POSIX ระบุพฤติกรรม "ดั้งเดิม C" ซึ่งมีเพียงตัวอักษร ASCII "A" ถึง "Z" เท่านั้นที่จะถือว่าเป็นตัวอักษรและการเรียงลำดับจะกระทำอย่างเคร่งครัดโดยค่าไบต์รหัสตัวอักษร ฉันคิดว่านี่เป็นตัวเลือกที่ดีที่สุดในกรณีนี้หรือฉันผิด (คำถามโบนัส: มันช้าเกินไปที่จะเลือกการเรียงในแบบสอบถามหรือไม่)

5
มี DBMS ที่อนุญาตให้ใช้ Foreign Key ที่อ้างอิงมุมมอง (และไม่เพียง แต่ตารางพื้นฐาน)?
แรงบันดาลใจจากการสร้างแบบจำลองคำถาม Django: การสร้างแบบจำลองฐานข้อมูลที่มีความสัมพันธ์หลายต่อหลายหลายใน Django การออกแบบ db เป็นสิ่งที่ชอบ: CREATE TABLE Book ( BookID INT NOT NULL , BookTitle VARCHAR(200) NOT NULL , PRIMARY KEY (BookID) ) ; CREATE TABLE Tag ( TagID INT NOT NULL , TagName VARCHAR(50) NOT NULL , PRIMARY KEY (TagID) ) ; CREATE TABLE BookTag ( BookID …

2
เกณฑ์การตัดสินใจว่าเมื่อใดควรใช้ schema ที่ไม่ใช่ dbo กับฐานข้อมูลใหม่
ฉันเป็นนักพัฒนาแอปพลิเคชั่นเป็นส่วนใหญ่ แต่พบว่าตัวเองต้องทำงานฐานข้อมูลล่วงหน้าทั้งหมดสำหรับโครงการปัจจุบันของฉัน ( btw ... MS SQL Server 2008 ) เป็นการตัดสินใจครั้งแรกฉันพยายามคิดว่าจะแบ่งสถานะของฉันโดยใช้ฐานข้อมูลแยกหรือใช้โครงสร้างของแยกในฐานข้อมูลเดียวกัน ฉันอ่าน SQL Server Schema เล็กน้อยและดูเหมือนว่าเป็นวิธีธรรมชาติในการแยกโดเมนวัตถุ ( ที่ฉันชอบ ) แต่ฉันไม่แน่ใจว่าอาจมีค่าใช้จ่ายแอบแฝงกับรูปแบบนี้ อะไรคือสิ่งที่ควรนำมาใช้ในการปฏิบัติมากขึ้นเมื่อเลือกระหว่างแนวทางทั้งสองนี้ หากฉันหลีกเลี่ยงการdbo.mytableสนับสนุนmyschema.mytableฉันจะสร้างความท้าทายอื่น ๆ ( หรือปัญหา ) สำหรับสถาปัตยกรรมของฉันหรือไม่ เป็นหมายเหตุด้านข้าง ... ณ จุดนี้จะถูกส่งไปยังDBA จริงเพื่อรักษา / สนับสนุนดังนั้นฉันพยายามทำให้แน่ใจว่าฉันจะไม่ทำให้ชีวิตของพวกเขายากขึ้น

8
ศาสตราจารย์บอกให้เราจัดเก็บวัตถุ Java ต่อเนื่องเป็น blobs แทนที่จะกำหนดตารางเชิงสัมพันธ์
แทนที่จะกำหนดตารางด้วยคุณสมบัติที่ถูกต้องจริง ๆ แล้วอาจารย์ของฉันบอกเราว่าเราสามารถแมปวัตถุกับรหัสเช่นนี้: id (int) | Serialized Object (blob) 1 10010110110 ฉันเห็นปัญหามากมายกับสิ่งนี้ การสำรองข้อมูลซ้ำซ้อนต้องติดตามรหัสแยกต่างหากโดยต้องดึงทั้งตารางในหน่วยความจำเพื่อค้นหาสิ่งใดและ ** หากฉันต้องการเปลี่ยนแบบจำลองของฉันในรหัส Java ฉันจะไม่สามารถลบข้อมูลหยดที่เก็บไว้ใน ฐานข้อมูลลงในโมเดลนั้น ไม่ว่าฉันจะติดอยู่กับโมเดลนั้นตลอดไปหรือฉันต้องทำสิ่งที่น่าเกลียดอื่น ๆ เพื่อเปลี่ยนโมเดลของฉัน ** สิ่งทั้งหมดนี้ดูเหมือนจะไม่ดีสำหรับฉัน ฉันเป็นธรรมในการไม่เห็นด้วยกับอาจารย์ของฉัน? มีประโยชน์ในการทำสิ่งนี้ที่ฉันไม่ได้คิด? ถ้าฉันถูกต้องฉันควรพูดอะไรบางอย่างกับอาจารย์ของฉันเกี่ยวกับเรื่องนี้? เขาเทศนาเรื่องนี้กับคนทั้งชั้นของฉันและยังบอกด้วยว่าเขาได้สร้างโครงการแบบนั้น ความคิดเห็นที่สองจะดีมาก หลักสูตรการตั้งชื่อการออกแบบซอฟแวร์ อาจารย์ของฉันไม่ได้บอกว่านี่เป็นวิธีที่ดีที่สุด แต่เขาบอกว่ามันเป็นทางเลือกที่ถูกกฎหมายในการกำหนดตารางเชิงสัมพันธ์ ตัวแบบไม่ได้มีการเคลื่อนไหว แต่อย่างใด

5
วิธีที่ดีที่สุดในการจัดเก็บหน่วยในฐานข้อมูล
ฉันได้รับมรดกฐานข้อมูลขนาดใหญ่ (SQLServer) ที่มีหลายร้อยคอลัมน์ที่แสดงจำนวนเงินของสิ่งใดสิ่งหนึ่ง หน่วยสำหรับค่าเหล่านี้ (เช่น "แกลลอน", "นิ้ว" และอื่น ๆ ) จะถูกเก็บไว้ในฟิลด์ MS_Description ของ Extended Properties ฉันสงสัยว่ามีวิธีที่ดีกว่าในการจัดเก็บข้อมูลนี้ ฉันคิดว่ามันเป็นเรื่องปกติสำหรับวัตถุประสงค์ในการจัดทำเอกสาร แต่มันยากที่จะทำการคำนวณการแปลงหน่วยที่แข็งแกร่งโดยใช้ข้อมูลนี้ ณ จุดนี้ฉันยังไม่พร้อมที่จะทำการเปลี่ยนแปลง แต่ถ้าฉันได้รับโอกาสทำเช่นนั้นแนวทางปฏิบัติที่ดีที่สุดที่แนะนำในเรื่องนี้คืออะไร? ตัวเลือกซึ่งอยู่ด้านบนของหัวของฉันอาจรวมถึง: เปลี่ยนชื่อคอลัมน์เป็นหน่วยที่รวมไว้ (เช่น "TotalVolumeInGallons" ซึ่งจะทำให้ข้อมูลพร้อมใช้งานได้ง่ายขึ้นเล็กน้อย แต่ก็ดูเหมือนว่าฉันจะอ่อนแอ) เพิ่มคอลัมน์ "หน่วย" แยกต่างหากเพื่อให้สอดคล้องกับทุกคอลัมน์ "จำนวน" (คอลัมน์นี้อาจเป็น nvarchar หรืออาจเป็นคีย์ต่างประเทศไปยังตารางหน่วยแยกต่างหากซึ่งอาจทำให้ง่ายต่อการคำนวณการแปลงหน่วยในอีกทางหนึ่ง คอลัมน์จำนวนมากสามารถเพิ่มขนาดฐานข้อมูลของฉันได้เป็นสองเท่า - ด้วยข้อมูลที่ซ้ำซ้อนมาก) สร้างฟิลด์ใหม่ในคุณสมบัติเพิ่มเติมสำหรับหน่วยโดยเฉพาะ (น่าเสียดายที่ฉันไม่คิดว่านี่จะเป็นคีย์ต่างประเทศในตารางหน่วย) มีแนวคิดอื่นอีกไหมที่ฉันมองเห็น UPDATE:หลังจากอ่านคำตอบของ @Todd Everett แล้วมีวิธีแก้ไขที่เป็นไปได้เกิดขึ้นกับฉันดังนั้นฉันจะดำเนินการต่อและตอบคำถามของฉันเอง (ดูด้านล่าง)


1
อะไรคือเหตุผลเบื้องหลังของทฤษฎีบท CAP?
http://en.wikipedia.org/wiki/CAP_theorem http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf ฉันคิดว่ามันไม่ได้ตรงไปตรงมามากว่าทำไมเพียงสองของ ความมั่นคง ความพร้อมใช้งาน ฉากกั้นห้อง สามารถเก็บไว้สำหรับระบบฐานข้อมูลแบบกระจายที่กำหนด การคาดเดานี้ได้รับการพิสูจน์แล้วว่า แต่จะมีวิธีที่ง่ายเพื่อดูว่าทำไมอาจนี้อาจถือ? ฉันไม่ได้มองหาหลักฐานเพียงวิธีที่ดีที่จะเข้าใจว่าทำไมทฤษฎีบทนี้จึงสมเหตุสมผล อะไรคือเหตุผล?

6
มีเครื่องมือที่ดีสำหรับการออกแบบฐานข้อมูลและต้นแบบหรือไม่ [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับผู้ดูแลฐานข้อมูล Exchange Exchange ปิดให้บริการใน5 ปีที่ผ่านมา ฉันต้องการเครื่องมือที่ดีสำหรับการออกแบบ Schema ฐานข้อมูลพร้อมกับตารางคอลัมน์ประเภทข้อมูลและความสัมพันธ์ทั้งหมด วันนี้ฉันทำด้วยปากกาและกระดาษเป็นส่วนใหญ่ แต่ฉันอยากจะทำมันในเครื่องมือออกแบบที่ดี มีเครื่องมือออกแบบฐานข้อมูลที่ดี (และฟรี) หรือไม่?

12
เหตุใดจึงมีข้อ จำกัด ในฐานข้อมูลมากกว่าใช้รหัส
เหตุใดจึงมีข้อ จำกัด ในฐานข้อมูล มันจะไม่ยืดหยุ่นกว่าที่จะใส่ไว้ในรหัสหรือไม่ ฉันกำลังอ่านหนังสือผู้เริ่มต้นใช้งานฐานข้อมูลดังนั้นฉันจึงขอให้เป็นผู้เริ่มต้น สมมติว่าฉันได้ออกแบบฐานข้อมูลรวมถึงโมเดลเอนทิตีนี้: entity type | sub-types ----------------+-------------------------------------------- Person | Employee, Student, ... Student | Graduate, Undergraduate, ... Employee | Teacher, Administrator, ... ข้อ จำกัด ในปัจจุบัน: ผู้ที่ลงทะเบียนในระบบสามารถเป็นนักเรียนหรือพนักงานเท่านั้น บุคคลนิติบุคคลต้องมีหมายเลขสังคมที่ไม่ซ้ำกันซึ่งเราสันนิษฐานว่าทุกคนมีเพียงหนึ่งเดียวที่ไม่ซ้ำกัน (aka, คีย์หลักที่ดีพอ ) (ดู # 1) ต่อมาเราตัดสินใจที่จะลบหมายเลข 1: หากวันหนึ่งวิทยาลัยตัดสินใจว่าTeacher( Employeeประเภทย่อย) สามารถทำได้เช่นStudentกันการเรียนในเวลาว่างของพวกเขามันยากมากที่จะเปลี่ยนการออกแบบฐานข้อมูลซึ่งอาจมีหลายพันล้านล้าน zillions ของรายการมากกว่าแค่การเปลี่ยนลอจิกในโค้ด: ส่วนที่ไม่อนุญาตให้บุคคลที่ลงทะเบียนทั้งในฐานะนักเรียนและพนักงาน (มันไม่น่าจะเป็นไปได้มาก แต่ฉันไม่สามารถนึกถึงสิ่งอื่นได้ในตอนนี้ เห็นได้ชัดว่าเป็นไปได้) ทำไมเราใส่ใจกฎธุรกิจในการออกแบบฐานข้อมูลมากกว่าในรหัส? # …

3
varchar (255) หรือ varchar (256)?
ฉันควรใช้varchar(255)หรือvarchar(256)เมื่อออกแบบตาราง? ฉันได้ยินมาว่ามีการใช้หนึ่งไบต์สำหรับความยาวของคอลัมน์หรือเพื่อเก็บข้อมูลเมตา มันสำคัญอีกต่อไปแล้ว ณ จุดนี้? ฉันเห็นโพสต์บนอินเทอร์เน็ตอย่างไรก็ตามพวกเขาใช้กับ Oracle และ MySQL เรามี Microsoft SQL Server 2016 Enterprise Edition แล้วนำไปใช้กับสภาพแวดล้อมนี้ได้อย่างไร ตอนนี้พูดตัวอย่างเช่นถ้าฉันบอกให้ลูกค้าของฉันเก็บตัวอย่างคำอธิบายข้อความถึง 255 ตัวอักษรแทน 256 จะมีความแตกต่าง? สิ่งที่ฉันอ่าน "ด้วยความยาวสูงสุด 255 อักขระ DBMS สามารถเลือกใช้ไบต์เดียวเพื่อระบุความยาวของข้อมูลในฟิลด์ถ้าขีด จำกัด เป็น 256 หรือมากกว่านั้นจำเป็นต้องใช้สองไบต์" มันเป็นเรื่องจริงเหรอ?

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