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

ฉันพยายามออกแบบฐานข้อมูลเพื่อให้สอดคล้องกับแนวคิดโครงการและพบกับสิ่งที่ดูเหมือนว่าจะเป็นประเด็นถกเถียงกันอย่างถึงพริกถึงขิง ฉันได้อ่านบทความไม่กี่คำและ Stack Overflow บางคำตอบที่ระบุว่าไม่เคย (หรือเกือบจะไม่เคย) ตกลงในการจัดเก็บรายการ ID หรือสิ่งที่ชอบในฟิลด์ - ข้อมูลทั้งหมดควรมีความสัมพันธ์ ฯลฯ อย่างไรก็ตามปัญหาที่ฉันพบคือฉันกำลังพยายามมอบหมายงาน ผู้คนจะสร้างงานมอบหมายให้คนหลายคนและมันจะบันทึกลงในฐานข้อมูล แน่นอนถ้าฉันบันทึกงานเหล่านี้ทีละรายการใน "บุคคล" ฉันจะต้องมีคอลัมน์ "TaskID" หลอกตานับสิบ ๆ ตัวและจัดการแบบไมโครเพราะจะมีงานมอบหมายให้บุคคลหนึ่งถึง 0 ถึง 100 จากนั้นอีกครั้งถ้าฉันบันทึกงานในตาราง "งาน" ฉันจะต้องมีคอลัมน์ "PersonID" หลอกตานับสิบ ๆ ตัวและจัดการกับมันแบบไมโคร - ปัญหาเช่นเดียวกับเมื่อก่อน สำหรับปัญหาเช่นนี้จะเป็นการดีไหมที่จะบันทึกรายการ ID ที่ใช้รูปแบบเดียวหรืออีกรูปแบบหนึ่งหรือฉันไม่คิดวิธีอื่นที่ทำได้โดยไม่ต้องทำลายหลักการ?

94 database  database-design  sql  relational-database 

ฉันกำลังเข้าใกล้โครงการที่ฉันจะต้องใช้ฐานข้อมูลกับเจ้านายของฉัน เราเริ่มต้นเพียงเล็กน้อยเพื่อให้สภาพแวดล้อมการทำงานมีความเป็นส่วนตัวอย่างลึกซึ้ง เขาให้ฐานข้อมูล บริษัท หนึ่งฐานแก่ฉันก่อนหน้านี้และตรงข้ามกับสิ่งที่ฉันได้รับการสอน (และอ่าน) ในโรงเรียนสำหรับ RDBMS ตัวอย่างเช่นมีฐานข้อมูลทั้งหมดที่นี่ซึ่งประกอบด้วยหนึ่งตาราง (ต่อฐานข้อมูลอิสระ) หนึ่งในตารางเหล่านั้นมีความยาว 20+ คอลัมน์และสำหรับบริบทนี่คือชื่อคอลัมน์บางส่วนจากตารางเดียว : lngStoreID | vrStoreName | lngCompanyID | vrCompanyName | lngProductID | vrProductName จุดที่เป็นที่ที่เขาควรจะมีตารางบุคคลที่เก็บข้อมูลกิจการ (ชื่อ, ขนาด, วันที่ซื้อ ฯลฯ ) เขาผลักมันทั้งหมดในตารางขนาดใหญ่หนึ่งต่อฐานข้อมูล ฉันต้องการปรับปรุงการออกแบบนี้ แต่ฉันไม่แน่ใจว่าทำไมตัวแบบข้อมูลที่ได้รับการทำให้เป็นมาตรฐานและจัดกลุ่มอย่างถูกต้องจะปรับปรุงผลิตภัณฑ์นี้ได้จริง ในขณะที่ฉันคุ้นเคยกับการออกแบบฐานข้อมูลจากวิทยาลัยและฉันเข้าใจวิธีการทำฉันไม่แน่ใจว่าทำไมสิ่งนี้ถึงช่วยปรับปรุงฐานข้อมูลได้จริง ทำไม schema เชิงสัมพันธ์ที่ดีจึงปรับปรุงฐานข้อมูล

61 database  relational-database 

จากประสบการณ์ของฉันหลายโครงการที่ฉันเคยอ่านในอดีตไม่ได้มีคำจำกัดความความสัมพันธ์ในฐานข้อมูล แต่พวกเขาเพียงกำหนดไว้ในซอร์สโค้ด ดังนั้นฉันสงสัยว่าอะไรคือข้อดี / ข้อเสียของการกำหนดความสัมพันธ์ระหว่างตารางในฐานข้อมูลและในซอร์สโค้ด? และคำถามที่กว้างขึ้นเกี่ยวกับคุณสมบัติขั้นสูงอื่น ๆ ในฐานข้อมูลที่ทันสมัยเช่นน้ำตก, ทริกเกอร์, ขั้นตอน ... มีบางจุดในความคิดของฉัน: ในฐานข้อมูล: แก้ไขข้อมูลจากการออกแบบ ป้องกันข้อผิดพลาดของแอปพลิเคชันซึ่งอาจทำให้ข้อมูลไม่ถูกต้อง ลดเครือข่ายไปกลับแอปพลิเคชันเมื่อทำการแทรก / อัปเดตข้อมูลเนื่องจากแอปพลิเคชันต้องทำแบบสอบถามเพิ่มเติมเพื่อตรวจสอบความถูกต้องของข้อมูล ในรหัสที่มา: ยืดหยุ่นมากขึ้น ดีกว่าเมื่อขยายไปยังหลายฐานข้อมูลเนื่องจากบางครั้งความสัมพันธ์สามารถข้ามฐานข้อมูลได้ ควบคุมความสมบูรณ์ของข้อมูลได้มากขึ้น ฐานข้อมูลไม่จำเป็นต้องตรวจสอบทุกครั้งที่แอปพลิเคชันแก้ไขข้อมูล (ความซับซ้อนสามารถเป็น O (n) หรือ O (n log n) (?)) แต่จะมอบให้กับแอปพลิเคชันแทน และฉันคิดว่าการจัดการความสมบูรณ์ของข้อมูลในแอปพลิเคชันจะทำให้เกิดข้อความแสดงข้อผิดพลาดมากกว่าการใช้ฐานข้อมูล เช่น: เมื่อคุณสร้างเซิร์ฟเวอร์ API หากคุณกำหนดความสัมพันธ์ในฐานข้อมูลและมีบางอย่างผิดปกติ (เช่นไม่มีเอนทิตีที่อ้างอิง) คุณจะได้รับ SQL Exception พร้อมข้อความ วิธีที่ง่ายคือการคืน 500 ให้กับลูกค้าว่ามีข้อผิดพลาด "เซิร์ฟเวอร์ภายใน" และลูกค้าจะไม่ทราบว่าเกิดอะไรขึ้น หรือเซิร์ฟเวอร์สามารถแยกวิเคราะห์ข้อความเพื่อหาว่ามีอะไรผิดปกติซึ่งเป็นวิธีที่น่าเกลียดและผิดพลาดในความคิดของฉัน หากคุณปล่อยให้แอปพลิเคชันจัดการกับสิ่งนี้ …

60 mysql  relational-database  schema  rdbms 

ฉันวางแผนที่จะออกแบบและตั้งค่าฐานข้อมูลเพื่อจัดเก็บรายการพจนานุกรม (มักเป็นคำเดียว) และความหมายของพวกเขาในภาษาอื่น ตัวอย่างเช่นตารางอภิธานศัพท์จะต้องมีรายการและคำนิยามและแต่ละระเบียนในตารางมีการอ้างอิงถึงidของบันทึกที่เก็บไว้ในTag(แต่ละรายการจะต้องมีแท็กหรือหมวดหมู่) เนื่องจากข้อมูลของฉันมีโครงสร้างฉันคิดว่าการใช้ฐานข้อมูล SQL (เช่น MySQL) ไม่ใช่ความคิดที่แย่ แต่ผู้คนบอกว่า MongoDB นั้นดีกว่ามากสำหรับประสิทธิภาพ ที่ฝั่งไคลเอ็นต์แอปพลิเคชันจะต้องสามารถให้ช่องค้นหาด้วยการเติมข้อความอัตโนมัติซึ่งใช้ REST API ที่แบ็กเอนด์จัดหาให้ ปลอดภัยที่จะไปกับ MySQL ในสถานการณ์เช่นนี้หรือไม่? หรือฉันควรใช้ MongoDB หรือ ElasticSearch ของการแก้ปัญหาอื่น ๆ สำหรับเรื่องนี้? ควรมีการจัดเก็บและเข้าถึงบันทึกหลายแสนรายการด้วยวิธีนี้

55 database-design  data-structures  mysql  relational-database  mongodb 

ฉันได้เรียนรู้เกี่ยวกับฐานข้อมูล NoSQL เป็นเวลาหนึ่งสัปดาห์แล้ว ฉันเข้าใจถึงข้อดีของฐานข้อมูล NoSQL และกรณีการใช้งานจำนวนมากที่ยอดเยี่ยม แต่บ่อยครั้งที่คนเขียนบทความราวกับว่า NoSQL สามารถแทนที่ฐานข้อมูลเชิงสัมพันธ์ได้ และมีจุดที่ฉันไม่สามารถไปรอบ ๆ : ฐานข้อมูล NoSQL เป็นที่เก็บคีย์ - ค่า (มัก) แน่นอนว่าเป็นไปได้ที่จะเก็บทุกอย่างไว้ในที่เก็บคีย์ - ค่า (โดยการเข้ารหัสข้อมูลใน JSON, XML, อะไรก็ตาม) แต่ปัญหาที่ฉันเห็นคือคุณต้องได้รับข้อมูลจำนวนหนึ่งที่ตรงกับเกณฑ์เฉพาะในหลาย ๆ ใช้กรณี ในฐานข้อมูล NoSQL คุณมีเกณฑ์เดียวคุณสามารถค้นหาได้อย่างมีประสิทธิภาพ - กุญแจ ฐานข้อมูลเชิงสัมพันธ์ได้รับการปรับปรุงเพื่อค้นหาค่าใด ๆ ในแถวข้อมูลได้อย่างมีประสิทธิภาพ ดังนั้นฐานข้อมูล NoSQL จึงไม่ใช่ทางเลือกสำหรับการเก็บข้อมูลที่ต้องการค้นหาเนื้อหาของพวกเขา หรือฉันเข้าใจผิดบางอย่าง? ตัวอย่าง: คุณต้องจัดเก็บข้อมูลผู้ใช้สำหรับ webshop ในฐานข้อมูลเชิงสัมพันธ์คุณเก็บผู้ใช้ทุกคนเป็นแถวในusersตารางโดยมี ID, ชื่อ, ประเทศของเขา ฯลฯ ในฐานข้อมูล NoSQL …

51 database  database-design  sql  nosql  relational-database 

เมื่อฉันตรวจสอบโมเดลฐานข้อมูลสำหรับ RDBMS ฉันมักจะประหลาดใจที่พบข้อ จำกัด เพียงเล็กน้อยหรือไม่มีเลย (นอกเหนือจาก PK / FK) ตัวอย่างเช่นเปอร์เซ็นต์มักถูกเก็บไว้ในคอลัมน์ประเภทint(ในขณะที่tinyintจะเหมาะสมกว่า) และไม่มีCHECKข้อ จำกัด ในการ จำกัด ค่าให้อยู่ในช่วง 0..100 ในทำนองเดียวกันกับ SE.SE คำตอบที่แนะนำข้อ จำกัด การตรวจสอบมักจะได้รับความคิดเห็นที่แนะนำว่าฐานข้อมูลเป็นสถานที่ที่ไม่ถูกต้องสำหรับข้อ จำกัด เมื่อฉันถามเกี่ยวกับการตัดสินใจที่จะไม่บังคับใช้ข้อ จำกัด สมาชิกในทีมตอบว่า: พวกเขาไม่รู้ด้วยซ้ำว่ามีคุณสมบัติดังกล่าวอยู่ในฐานข้อมูลที่ชื่นชอบ เป็นที่เข้าใจได้จากโปรแกรมเมอร์ที่ใช้ ORM เท่านั้น แต่น้อยกว่ามากจาก DBA ที่อ้างว่ามีประสบการณ์มากกว่า 5 ปีกับ RDBMS ที่กำหนด หรือว่าพวกเขาบังคับใช้ข้อ จำกัด ดังกล่าวในระดับแอปพลิเคชันและการทำซ้ำกฎเหล่านั้นในฐานข้อมูลไม่ใช่ความคิดที่ดีละเมิด SSOT เมื่อเร็ว ๆ นี้ฉันเห็นโครงการมากขึ้นเรื่อย ๆ ซึ่งไม่ได้ใช้กุญแจต่างประเทศ ในทำนองเดียวกันฉันได้เห็นความคิดเห็นเล็กน้อยที่นี่ใน SE.SE ซึ่งแสดงให้เห็นว่าผู้ใช้ไม่สนใจการอ้างอิงที่สมบูรณ์มากนักทำให้แอปพลิเคชันจัดการกับมัน เมื่อถามทีมถึงทางเลือกที่จะไม่ใช้ FK …

46 database-design  relational-database  rules-and-constraints 

ฉันกำลังทำงานกับฐานข้อมูล SQL อยู่ในขณะนี้และสิ่งนี้ทำให้ฉันสงสัยอยู่เสมอ แต่การค้นหาของ Google ไม่ได้เกิดอะไรขึ้น: ทำไมประเภทข้อมูลที่เข้มงวด ฉันเข้าใจว่าทำไมคุณต้องการมีไม่กี่ชนิดข้อมูลที่แตกต่างกันตัวอย่างเช่นวิธีการแตกต่างระหว่างข้อมูลที่เป็นข้อความธรรมดาไบนารีและเป็นสิ่งสำคัญ แทนที่จะเก็บข้อมูลไบนารี 1 และ 0s เป็นข้อความธรรมดาตอนนี้ฉันเข้าใจว่ามันมีประสิทธิภาพมากกว่าในการจัดเก็บข้อมูลไบนารีเป็นรูปแบบของตัวเอง แต่สิ่งที่ฉันไม่เข้าใจคือสิ่งที่ประโยชน์คือการมีประเภทข้อมูลที่แตกต่างกันมากมาย : ทำไมmediumtext, longtextและtext? ทำไมdecimal, floatและint? เป็นต้น ประโยชน์ของการบอกฐานข้อมูลคืออะไร "จะมีเพียง 256 ไบต์ของข้อมูลข้อความธรรมดาในรายการในคอลัมน์นี้" หรือ "คอลัมน์นี้สามารถมีรายการข้อความได้ถึง 16,777,215 ไบต์" มันเป็นผลประโยชน์ด้านประสิทธิภาพหรือไม่? ถ้าใช่ทำไมรู้ขนาดของรายการก่อนมือช่วยประสิทธิภาพ? หรือค่อนข้างเป็นอย่างอื่นทั้งหมด?

44 database  sql  relational-database  data-types 

สำหรับวัตถุประสงค์ของการสนทนาลองพิจารณาสถานการณ์จำลองของ FourSquare สถานการณ์ หน่วยงาน: ผู้ใช้ สถานที่ ความสัมพันธ์: Checkins: ผู้ใช้ <-> สถานที่หลายแห่งไปมาก เพื่อน: ผู้ใช้ <-> ผู้ใช้หลายต่อหลายคน การออกแบบฐานข้อมูล สิ่งเหล่านี้มักจะมีข้อผิดพลาดโปรดชี้ให้พวกเขาเห็น RDBMS โต๊ะ: ผู้ใช้ สถานที่ เช็คอิน (แยก) เพื่อน (แยก) ข้อดี: CAP: ความสอดคล้องความพร้อมใช้งาน จุดด้อย: CAP: ความอดทนต่อการแบ่งพาร์ทิชัน schemes = โครงสร้างที่ไม่ยืดหยุ่น การจำลองแบบไม่ดี? กราฟ วัตถุที่: ผู้ใช้ สถานที่ ขอบ: เพื่อน: ผู้ใช้ <-> ผู้ใช้ เช็คอิน: ผู้ใช้ -> สถานที่ มีการประทับเวลา ข้อดี: …

29 database  database-design  relational-database  document-databases  graph-databases 

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

23 design  sql  database-design  relational-database  rdbms 

ฉันพยายามที่จะเข้าใจวิธีการจัดเก็บข้อมูลที่สั่งซื้ออย่างถูกต้องในฐานข้อมูลเชิงสัมพันธ์ ตัวอย่าง: สมมติว่าฉันมีเพลย์ลิสต์ประกอบด้วยเพลง ภายในฐานข้อมูลเชิงสัมพันธ์ของฉันฉันมีสารบัญPlaylistsประกอบด้วยข้อมูลเมตาบางส่วน (ชื่อผู้สร้าง ฯลฯ ) ฉันยังมีตารางที่เรียกว่าSongsที่มีข้อมูลplaylist_idรวมถึงข้อมูลเฉพาะเพลง (ชื่อศิลปินระยะเวลา ฯลฯ ) ตามค่าเริ่มต้นเมื่อมีการเพิ่มเพลงใหม่ลงในเพลย์ลิสต์เพลงจะถูกต่อท้าย เมื่อสั่งซื้อบน Song-ID (น้อยไปหามาก) คำสั่งซื้อจะเป็นลำดับของการเพิ่ม แต่ถ้าหากผู้ใช้สามารถสั่งซื้อเพลงในรายการเพลงได้อีกครั้ง ฉันคิดไอเดียสองสามข้อแต่ละข้อมีข้อดีและข้อเสีย: คอลัมน์เรียกว่าorderซึ่งเป็นจำนวนเต็ม เมื่อเพลงถูกย้ายลำดับของเพลงทั้งหมดระหว่างตำแหน่งเก่าและตำแหน่งใหม่จะเปลี่ยนไปเพื่อให้สอดคล้องกับการเปลี่ยนแปลง ข้อเสียของเรื่องนี้คือต้องมีการค้นหาจำนวนมากในแต่ละครั้งที่มีการย้ายเพลงและอัลกอริทึมการย้ายนั้นไม่สำคัญกับตัวเลือกอื่น ๆ คอลัมน์ที่เรียกว่าorderซึ่งเป็นทศนิยม ( NUMERIC) เมื่อเพลงถูกย้ายมันจะถูกกำหนดค่าจุดลอยตัวระหว่างตัวเลขสองตัวที่อยู่ติดกัน ข้อเสียเปรียบ: เขตข้อมูลทศนิยมใช้เนื้อที่มากขึ้นและอาจเป็นไปได้ที่จะใช้ความแม่นยำจนหมดเว้นแต่จะได้รับการดูแลเพื่อกระจายช่วงใหม่หลังจากการเปลี่ยนแปลงทุกครั้ง อีกวิธีหนึ่งก็คือการมีpreviousและnextฟิลด์ที่อ้างอิงเพลงอื่น ๆ (หรือเป็น NULL ในกรณีของเพลงแรก, resp. เพลงสุดท้ายในเพลย์ลิสต์ในขณะนี้โดยทั่วไปคุณสร้างรายการที่ลิงก์ ) ข้อเสียเปรียบ: ข้อความค้นหาเช่น 'find Xth Song ในรายการ' ไม่ใช่เวลาคงที่อีกต่อไป แต่จะเป็นเวลาเชิงเส้นแทน ขั้นตอนใดที่ใช้บ่อยที่สุดในการปฏิบัติ? ขั้นตอนใดที่เร็วที่สุดสำหรับฐานข้อมูลขนาดกลางถึงขนาดใหญ่ มีวิธีอื่นอีกไหมในการเก็บเรื่องนี้? แก้ไข:เพื่อความง่ายในตัวอย่างเพลงเป็นของเพลย์ลิสต์เดียวเท่านั้น (ความสัมพันธ์แบบหนึ่งต่อหนึ่ง) แน่นอนเราสามารถใช้ …

20 database  database-design  sorting  array  relational-database 

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

19 database  agile  domain-driven-design  relational-database  ooad 

ถ้าฉันเข้าใจถูกต้องทุกคนRIGHT JOIN: SELECT Persons.*, Orders.* FROM Orders RIGHT JOIN Persons ON Orders.PersonID = Persons.ID สามารถแสดงเป็นLEFT JOIN: SELECT Persons.*, Orders.* FROM Persons LEFT JOIN Orders ON Persons.ID = Orders.PersonID ความคิดเห็นส่วนตัวของฉันคือเจตนาของแถลงการณ์: ก่อนได้รับ Persons จากนั้นขยาย / ทำซ้ำPersonsตามที่จำเป็นเพื่อให้ตรงกับOrders แสดงได้ดีกว่าโดยคำสั่งของPersons LEFT JOIN Ordersกว่าสั่งย้อนกลับOrders RIGHT JOIN Persons(และฉันไม่เคยใช้RIGHT JOINเป็นผล) มีสถานการณ์ใดบ้างที่RIGHT JOINเป็นที่ต้องการ? หรือมีกรณีการใช้งานที่RIGHT JOINสามารถทำสิ่งที่LEFT JOINไม่สามารถ?

18 database-design  sql  relational-database 

ฉันเป็นคน SQL แต่ฉันรู้ว่ามีฐานข้อมูลSQL ไม่เพียง - ฐานข้อมูลเอกสารส่วนใหญ่ เช่นเดียวกับเทคโนโลยีส่วนใหญ่มีข้อดีและข้อเสียสำหรับแต่ละเทคโนโลยี ฉันได้อ่านบทความมาแล้ว แต่พวกเขาก็มีเหตุผลมากเกินไป สิ่งที่ฉันต้องการคือสองกรณีจริง: เมื่อเปลี่ยนจาก relational- เป็น document-database ให้การปรับปรุง เมื่อเปลี่ยนจากเอกสาร - เป็นฐานข้อมูลเชิงสัมพันธ์ให้การปรับปรุง การปรับปรุงเป็นสิ่งที่ทำให้โปรแกรมดีขึ้น - ลดเวลาในการพัฒนาน้อยลง, ปรับขนาดได้, ประสิทธิภาพ, ทุกอย่างที่เกี่ยวข้องกับการเขียนโปรแกรม มีข้อแม้สำหรับ 2: เรื่องราวเช่น "ถอยกลับไปยังฐานข้อมูลเชิงสัมพันธ์เพราะทุกคนรู้ว่า SQL" ไม่ดี

16 nosql  relational-database 

แค่อ่านบรรทัดเหล่านี้ - หากข้อมูลของคุณเป็นวัตถุโดยทั่วไปให้ใช้ที่เก็บวัตถุ ("NoSQL") มันจะเร็วกว่าฐานข้อมูลเชิงสัมพันธ์ หากข้อมูลของคุณเป็นแบบเชิงสัมพันธ์ค่าใช้จ่ายของฐานข้อมูลเชิงสัมพันธ์จะคุ้มค่า จาก- http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern ดังนั้นฉันจะรู้ได้อย่างไรว่าข้อมูลของฉันสัมพันธ์ในลักษณะเชิงวัตถุหรือไม่?

16 object-oriented  database  relational-database 

ว่าฉันมีแผนภาพ ER ต่อไปนี้: ตอนนี้ถ้าฉันแสดงถึงความสัมพันธ์โดยใช้ foreign key ของSchoolin StudentฉันสามารถมีNULLค่าได้(เนื่องจาก a Student ไม่จำเป็นต้องเป็นของ a School) ตัวอย่างเช่น: ดังนั้นวิธีที่ถูกต้อง (ขึ้นอยู่กับสิ่งที่ฉันได้อ่าน) คือการสร้างตารางสี่แยกเพื่อเป็นตัวแทนของความสัมพันธ์ตัวอย่างเช่น วิธีนี้ไม่มีค่าสามารถจะนำเสนอในตารางNULLSchool_has_Student แต่อะไรคือข้อเสียของการใช้ foreign key แบบ nullable แทนการสร้างตาราง intersection? แก้ไข: ฉันเลือก ( school_id, student_id) เป็นคีย์หลักสำหรับSchool_has_Studentตารางโดยไม่ตั้งใจซึ่งทำให้ความสัมพันธ์แบบนี้มีมากหลายต่อหลายคน คีย์หลักที่ถูกต้องควรเป็นstudent_id:

15 database  database-design  relational-database