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

ฉันมีคำถามทั่วไปเกี่ยวกับฐานข้อมูล เรามักจะใช้คำเปรียบเทียบกับฐานข้อมูล ฉันอยากจะรู้ว่ามันแตกต่างจากชุดตัวละครอย่างไร ฉันเดาว่า collation เป็นเซตย่อยของชุดตัวละคร หากเป็นจริงวัตถุประสงค์ในการเปรียบเทียบหลายครั้งภายใต้ชุดอักขระคืออะไร

24 database  mysql  database-design 

แอปพลิเคชันจำนวนมากรวมถึง 'ข้อมูลคงที่': ข้อมูลที่ไม่เปลี่ยนแปลงในช่วงอายุของแอปพลิเคชัน ตัวอย่างเช่นคุณอาจมีรายการพื้นที่ขายที่น่าจะเป็นรายการคงที่สำหรับอนาคตที่มองเห็นได้ ไม่ใช่เรื่องแปลกที่จะหาข้อมูลคงที่นี้ในตารางฐานข้อมูล (บ่อยครั้งเพราะคุณต้องการอ้างถึงในคีย์ต่างประเทศของตารางอื่น ๆ ) ตารางตัวอย่างง่าย ๆ จะมีรหัสที่ใช้เป็นคีย์หลักและคำอธิบาย ตัวอย่างเช่นตาราง SalesArea ของคุณจะมี (อย่างน้อย) คอลัมน์ SalesAreaId และคอลัมน์ SalesAreaDescription ตอนนี้ในรหัสคุณอาจไม่ต้องการให้แต่ละแถวของตารางเหมือนกัน ตัวอย่างเช่นคุณอาจต้องการตั้งค่าพื้นที่ขายเริ่มต้นในบางหน้าจอระบุตัวเลขที่แตกต่างกันสำหรับบางพื้นที่หรือ จำกัด สิ่งที่ผู้ใช้สามารถทำได้ในพื้นที่อื่น วิธีที่ดีที่สุดในการอ้างถึงข้อมูลคงที่ในรหัสคืออะไร? ทำไม? เขียนโค้ดรายละเอียดในรหัสของคุณ ใช้สิ่งนี้เพื่อค้นหา SalesAreaId จากฐานข้อมูลเมื่อคุณต้องการ รหัสฮาร์ดโค้ดในรหัสของคุณ ใช้สิ่งนี้เพื่อค้นหา SalesAreaDescription เมื่อคุณต้องการ เพิ่มคอลัมน์ลงในตารางสำหรับแต่ละวัตถุประสงค์เช่นคอลัมน์ "IsDefaultOnProductLaunchScreen" และอื่น ๆ (อาจมีจำนวนมาก) อื่น ๆ อีก. มีข้อควรพิจารณาพิเศษอื่นใดอีกไหมที่ฉันควรทำเมื่อจัดการกับข้อมูลฐานข้อมูลแบบคงที่? ตัวอย่างเช่นการตั้งชื่อตารางเหล่านี้เป็นพิเศษ?

24 database-design 

เป็นฐานข้อมูลผู้เช่าหลายคน: เซิร์ฟเวอร์ฐานข้อมูลที่มีฐานข้อมูล / สคีมาแตกต่างกันสำหรับลูกค้า / ผู้เช่าแต่ละราย หรือ เซิร์ฟเวอร์ฐานข้อมูลที่มีฐานข้อมูล / สคีมาที่ลูกค้า / ผู้เช่าแบ่งปันบันทึกภายในตารางเดียวกันหรือไม่ ตัวอย่างเช่นภายใต้ตัวเลือก # 1 ด้านบนฉันอาจมีเซิร์ฟเวอร์ MySQL ที่พูดmydb01.example.comและอาจมีcustomer1ฐานข้อมูลอยู่ภายใน customer1ฐานข้อมูลนี้อาจมี 10 ตารางที่เพิ่มประสิทธิภาพแอปพลิเคชันของฉันสำหรับลูกค้ารายนั้น (ลูกค้า # 1) มันอาจจะมีcustomer2ฐานข้อมูลที่มี 10 ตารางเหมือนกัน แต่มีเพียงข้อมูลสำหรับลูกค้า # 2 มันอาจมีcustomer3ฐานcustomer4ข้อมูลฐานข้อมูลและอื่น ๆ ในตัวเลือก # 2 ด้านบนจะมีเพียงฐานข้อมูล / สคีเดียวเท่านั้นพูดmyapp_dbอีกครั้งโดยมี 10 ตารางอยู่ (เหมือนที่อยู่ด้านบน) แต่ที่นี่ข้อมูลสำหรับลูกค้าทั้งหมดอยู่ใน 10 ตารางเหล่านั้นและพวกเขาจึง "แบ่งปัน" ตาราง และที่ชั้นแอปพลิเคชันการควบคุมตรรกะและความปลอดภัยซึ่งลูกค้าสามารถเข้าถึงได้ว่าระเบียนใดบ้างใน 10 ตารางดังกล่าวและมีการดูแลอย่างดีเยี่ยมเพื่อให้แน่ใจว่าลูกค้า # …

24 database-design  multitenancy 

สิ่งนี้ได้ดักฟังฉันมาระยะหนึ่งแล้ว เวลาส่วนใหญ่เมื่อมันมาถึงการจัดเก็บข้อมูลในโครงสร้างเช่นแฮชเทเบิลโปรแกรมเมอร์หนังสือและบทความยืนยันว่าองค์ประกอบการจัดทำดัชนีในโครงสร้างดังกล่าวโดยค่าสตริงถือว่าเป็นการปฏิบัติที่ไม่ดี ถึงกระนั้นฉันยังไม่พบแหล่งข้อมูลดังกล่าวเพียงแหล่งเดียวเพื่ออธิบายว่าทำไมจึงถือว่าเป็นการปฏิบัติที่ไม่ดี มันขึ้นอยู่กับภาษาการเขียนโปรแกรมหรือไม่? ในกรอบพื้นฐาน? เกี่ยวกับการใช้งานหรือไม่ ยกตัวอย่างง่ายๆสองอย่างถ้าช่วยได้: ตารางคล้าย SQL ที่แถวถูกทำดัชนีโดยคีย์หลักของสตริง . NET Dictionary ที่มีรหัสเป็น Strings

24 programming-practices  data-structures  database-design 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันเพิ่งเรียนหลักสูตรการออกแบบซอฟต์แวร์และมีการอภิปราย / ข้อเสนอแนะล่าสุดเกี่ยวกับการใช้แบบจำลอง 'บริการขนาดเล็ก' โดยที่ส่วนประกอบของบริการจะถูกแยกออกเป็นส่วนย่อยของบริการ microservice ที่เป็นอิสระที่สุด ส่วนหนึ่งที่ถูกกล่าวถึงนั้นแทนที่จะทำตามรูปแบบที่เห็นได้บ่อยมากของการมีฐานข้อมูลเดียวที่ไมโครไซต์ทั้งหมดพูดถึงคุณจะมีฐานข้อมูลแยกต่างหากที่ทำงานสำหรับไมโครไซต์แต่ละรายการ คุณสามารถอ่านคำอธิบายที่ละเอียดและมีรายละเอียดมากขึ้นเกี่ยวกับสิ่งนี้ได้ที่นี่: http://martinfowler.com/articles/microservices.htmlภายใต้หัวข้อการจัดการข้อมูลแบบกระจายอำนาจ ส่วนที่สำคัญที่สุดที่พูดนี้: Microservices ต้องการให้แต่ละบริการจัดการฐานข้อมูลของตัวเองไม่ว่าจะเป็นอินสแตนซ์ที่แตกต่างกันของเทคโนโลยีฐานข้อมูลเดียวกันหรือระบบฐานข้อมูลที่แตกต่างกันโดยสิ้นเชิง - แนวทางที่เรียกว่า Polyglot Persistence คุณสามารถใช้การคงอยู่หลายภาษาในหินใหญ่ก้อนเดียว แต่ปรากฏขึ้นบ่อยครั้งด้วย microservices รูปที่ 4 ฉันชอบแนวคิดนี้และในหลาย ๆ สิ่งเห็นว่าการปรับปรุงที่ดีในการบำรุงรักษาและการมีโครงการที่มีหลายคนทำงานอยู่ ที่กล่าวว่าฉันไม่เคยมีประสบการณ์สถาปนิกซอฟต์แวร์ มีใครเคยลองใช้บ้างไหม คุณได้ประโยชน์อะไรและอุปสรรคอะไรบ้าง?

23 design  database-design  microservices 

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

23 design  sql  database-design  relational-database  rdbms 

ในบางตารางของฉันฉันต้องการเพิ่ม "second_primary_key" ซึ่งจะเป็น uuid หรือบางคีย์ยาวแบบสุ่ม ฉันต้องการเพราะบางตารางฉันไม่ต้องการให้จำนวนเต็มกับเว็บแอปพลิเคชันของฉัน นั่นคือในหน้า "/ ใบแจ้งหนี้" ฉันมีรายการใบแจ้งหนี้และลิงก์ไปยัง "/ ใบแจ้งหนี้ /: id" โดยที่: id เป็นจำนวนเต็ม ฉันไม่ต้องการให้ผู้ใช้ทราบจำนวนใบแจ้งหนี้ในระบบของฉันที่นั่นดังนั้นแทนที่จะเป็น "/ ใบแจ้งหนี้ / 123" ฉันต้องการใช้ "second_primary_key" เพื่อให้ URL เป็น "/ ใบแจ้งหนี้ / N_8Zk241vNa" เช่นเดียวกันกับตารางอื่น ๆ ที่ฉันต้องการซ่อนรหัสจริง ฉันสงสัยว่านี่เป็นเรื่องธรรมดาหรือไม่ วิธีที่ดีที่สุดในการใช้งานนี้คืออะไร และเทคนิคนี้เรียกว่าอะไรหลังจากทั้งหมดเพื่อที่ฉันจะค้นหามัน?

22 database  database-design 

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

20 database  database-design  sorting  array  relational-database 

มีเหตุผลใดที่จะสร้างข้อ จำกัด ระหว่างตาราง (ภายใน SQLserver) ทุกวันนี้? ถ้าเป็นเช่นนั้นเมื่อไหร่? แอปพลิเคชั่นส่วนใหญ่ในพื้นที่ของฉันสร้างขึ้นตามหลักการของวัตถุและตารางจะเข้าร่วมได้ตามต้องการ ความต้องการขึ้นอยู่กับความต้องการจากแอปพลิเคชัน ฉันจะไม่โหลดตารางที่ จำกัด สำหรับการค้นหาอย่างง่ายซึ่งในทางกลับกัน (หลังจากการกระทำ) ต้องใช้การค้นหาแบบง่ายอีกอันหนึ่ง เครื่องมือ ORM เช่น EntityContext, Linq2Data, NHibernate ยังจัดการกับข้อ จำกัด ด้วยตัวเองอย่างน้อยคุณก็รู้ว่าตารางใดที่ต้องการซึ่งกันและกัน การทำข้อ จำกัด ภายในเซิร์ฟเวอร์นั้นเกี่ยวกับการเปลี่ยนแปลง (บังคับ) เดียวกันสองครั้งหรือไม่? นี่ไม่ใช่คำถามสำหรับการตัดสินใจ แต่ฐานข้อมูลนี้ออกแบบแตกต่างกันมาก การออกแบบดูดีปกติสะท้อนวัตถุที่ใช้โดยแอพพลิเคชั่นเป็นส่วนใหญ่ สิ่งที่รบกวนฉันคือข้อ จำกัด ทั้งหมดที่กำหนดค่าไว้ภายใน SQLserver ด้วย "not cascade" ซึ่งหมายความว่าคุณต้องเล่น "ค้นหาและค้นหา" เมื่อเข้ารหัสคิวรีฐานข้อมูลใหม่ บางกรณีต้องการคำสั่งซื้อที่แน่นอนถึง 10 ระดับเพื่อทำการลบแบบครั้งเดียว เรื่องนี้ทำให้ฉันประหลาดใจและฉันไม่แน่ใจว่าจะจัดการกับมันอย่างไร ในโลกเรียบง่ายของฉันการตั้งค่านั้นทำให้ข้อ จำกัด สูญเสียจุดประสงค์ส่วนใหญ่ ตกลงถ้าฐานข้อมูลถูกเข้าถึงจากโฮสต์ที่ไม่มีความรู้ด้านการออกแบบ คุณจะทำอย่างไรในสถานการณ์นี้ …

20 .net  database  database-design 

เรามีลูกค้าจำนวนมากที่มีระบบแบ่งปันฟังก์ชั่นบางอย่าง แต่ก็มีความหลากหลายในระดับหนึ่ง จำนวนลูกค้ากำลังเติบโต - เป็นสิ่งที่ดีต่อสุขภาพเสมอ! - และความหลากหลายระหว่างธุรกิจของพวกเขาก็เพิ่มขึ้นเช่นกัน ในปัจจุบันมีเว็บไซต์ ASP.Net (แบบฟอร์มบนเว็บ) เดียว (ตรงข้ามกับโครงการเว็บ) ซึ่งมีโฟลเดอร์ย่อยสำหรับผู้เช่าแต่ละรายโดยมีหน้าที่ไม่ได้มาตรฐานของผู้เช่ารายนั้น มีโครงการแบบแยกต่างหากซึ่งเกี่ยวข้องกับการเข้าถึงฐานข้อมูลและตรรกะทางธุรกิจ ข้อไหนดีกว่าและที่สำคัญที่สุดคือทำไมระหว่างการมี (a) 1 ฐานข้อมูลต่อลูกค้าโดยมีเฉพาะคุณสมบัติที่เกี่ยวข้องกับไคลเอ็นต์นั้น หรือ (b) ฐานข้อมูลเดียวที่ใช้ร่วมกันโดยไคลเอนต์ทั้งหมดที่มีเพียงส่วนย่อยของตารางที่จะใช้โดยลูกค้ารายใดรายหนึ่ง ความกังวลหลักภายในธุรกิจมีมากกว่า: การบำรุงรักษาสินทรัพย์หลายรายการ - การสำรองข้อมูลการควบคุมเวอร์ชันและสิ่งที่คล้ายกัน ส่งเสริมการใช้ซ้ำให้มากที่สุด คุณจะมั่นใจได้อย่างไรว่าปัญหาเหล่านี้ได้รับการแก้ไขซึ่งเป็นวิธีที่เหมาะสมกว่าและทำไม (ฉันได้รวบรวมคำตอบสำหรับคำถามที่คล้ายกันด้วย)

20 database-design  projects-and-solutions  multitenancy 

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

20 database-design  null 

สถานการณ์คือว่าฉันมีกลุ่มผู้ใช้ที่เพิ่มขึ้นและเมื่อเวลาผ่านไปผู้ใช้จะยกเลิกบัญชีของพวกเขาที่เราทำเครื่องหมายว่า 'ลบ' (ด้วยการตั้งค่าสถานะ) ในตารางเดียวกัน หากผู้ใช้ที่มีที่อยู่อีเมลเดียวกัน (นั่นคือวิธีการที่ผู้ใช้ลงชื่อเข้าใช้) ต้องการสร้างบัญชีใหม่พวกเขาสามารถลงทะเบียนอีกครั้ง แต่สร้างบัญชีใหม่ (เรามีรหัสประจำตัวที่ไม่ซ้ำกันสำหรับทุกบัญชีดังนั้นที่อยู่อีเมลจึงสามารถทำซ้ำได้ทั้งแบบสดและถูกลบ) สิ่งที่ฉันได้สังเกตเห็นว่าทั่วทั้งระบบของเราตามปกติของสิ่งที่เราอย่างต่อเนื่องสอบถามตารางการตรวจสอบผู้ใช้ผู้ใช้จะไม่ถูกลบในขณะที่สิ่งที่ฉันคิดคือการที่เราไม่จำเป็นต้องทำอย่างนั้นเลย ... ! [ชี้แจง 1: โดย 'ค้นหาอย่างต่อเนื่อง' ฉันหมายถึงเรามีข้อความค้นหาที่เป็นเช่น: '... จากผู้ใช้ WHERE isdeleted = "0" AND ... ' ตัวอย่างเช่นเราอาจต้องดึงข้อมูลผู้ใช้ทั้งหมดที่ลงทะเบียนสำหรับการประชุมทั้งหมดในวันที่ระบุดังนั้นในการค้นหานั้นเรายังมีผู้ใช้จากที่ไหน WHERE isdeleted = "0" - สิ่งนี้ทำให้ประเด็นของฉันชัดเจนขึ้นหรือไม่] (1) continue keeping deleted users in the 'main' users table (2) keep deleted users in a separate …

19 database  database-design 

คำถามนี้เกี่ยวกับวิธีที่ฉันควรออกแบบฐานข้อมูลมันอาจเป็นฐานข้อมูลเชิงสัมพันธ์ / nosql ขึ้นอยู่กับสิ่งที่จะเป็นทางออกที่ดีกว่า กำหนดข้อกำหนดที่คุณจะต้องสร้างระบบที่จะเกี่ยวข้องกับฐานข้อมูลเพื่อติดตาม "บริษัท " และ "ผู้ใช้" ผู้ใช้คนเดียวเป็นของ บริษัท เดียวเสมอ ผู้ใช้สามารถเป็นของ บริษัท เดียวเท่านั้น บริษัท สามารถมีผู้ใช้หลายคน การออกแบบสำหรับตาราง "บริษัท " ค่อนข้างตรงไปตรงมา บริษัท จะมีคุณสมบัติ / คอลัมน์ต่อไปนี้: (ขอให้ง่าย) ID, COMPANY_NAME, CREATED_ON สถานการณ์แรก เรียบง่ายและตรงไปตรงมาผู้ใช้ทุกคนมีคุณลักษณะเดียวกันดังนั้นสิ่งนี้สามารถทำได้อย่างง่ายดายในลักษณะสัมพันธ์ตารางผู้ใช้: ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON สถานการณ์ที่สอง จะเกิดอะไรขึ้นหาก บริษัท ต่าง ๆ ต้องการจัดเก็บแอตทริบิวต์โปรไฟล์ที่แตกต่างกันสำหรับผู้ใช้ แต่ละ บริษัท จะมีชุดแอตทริบิวต์ที่กำหนดไว้ซึ่งจะใช้กับผู้ใช้ทั้งหมดของ บริษัท นั้น ตัวอย่างเช่น: บริษัท …

18 database  database-design  sql  nosql 

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

18 database  database-design  mysql  debugging  logging 

ถ้าฉันเข้าใจถูกต้องทุกคน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