ฉันควรใช้หนึ่งฐานข้อมูลต่อแอปพลิเคชันหรือแชร์ฐานข้อมูลเดียวระหว่างแอปพลิเคชันหลาย ๆ ตัว

ฉันมีหลายแอพพลิเคชั่นบางตัวที่ใช้ข้อมูลจากแหล่งเดียวกัน เป็นการปฏิบัติที่ดีที่สุด (หรือข้อดี / ข้อเสีย) คือ:

• ปล่อยให้ข้อมูลในฐานข้อมูลที่ใช้ร่วมกันหลายแอปพลิเคชัน

  1. ประหยัดพื้นที่เนื่องจากต้องการเพียงหนึ่งฐานข้อมูล
  2. การทำดัชนีมีความซับซ้อนเนื่องจากแอปพลิเคชันต่าง ๆ มีความต้องการการสืบค้นที่แตกต่างกัน

• นำเข้าข้อมูลรายวันไปยังฐานข้อมูลต่อแอป

  1. ใช้พื้นที่มากขึ้นเนื่องจากมีข้อมูลซ้ำกันในฐานข้อมูลต่อแอป
  2. การจัดทำดัชนีง่ายขึ้นเนื่องจากแต่ละแอพสามารถมุ่งเน้นที่ความต้องการส่วนบุคคล

ฉันอาจจะทิ้งข้อดี / ข้อเสียอื่น ๆ โปรดระบุถ้ามีและสิ่งนี้จะเกิดขึ้นในที่ทำงานของคุณได้อย่างไร?

วันนี้ Space มีราคาถูกดังนั้นฉันแนะนำให้ใช้หนึ่งฐานข้อมูลต่อแอปพลิเคชัน

ฐานข้อมูลที่ใช้ร่วมกันในหมู่หนึ่งสำหรับการใช้งานหลายมีบางอย่างข้อเสีย :

• การใช้งานที่มากขึ้นใช้ฐานข้อมูลเดียวกันมีโอกาสมากขึ้นก็คือการที่คุณตี bottlenecks ประสิทธิภาพและการที่คุณไม่สามารถได้อย่างง่ายดายขนาดโหลดตามต้องการ ฐานข้อมูล SQL ไม่ได้ปรับขนาดจริงๆ คุณสามารถซื้อเครื่องจักรที่มีขนาดใหญ่กว่า แต่เครื่องเหล่านี้มีขนาดไม่ใหญ่นัก!

• ค่าใช้จ่ายในการบำรุงรักษาและการพัฒนาสามารถเพิ่มขึ้นได้ : การพัฒนานั้นยากขึ้นหากแอปพลิเคชันจำเป็นต้องใช้โครงสร้างฐานข้อมูลที่ไม่เหมาะกับงานในมือ แต่จะต้องใช้ตามที่มีอยู่แล้ว อาจเป็นไปได้ว่าการปรับแอปพลิเคชันหนึ่งจะมีผลข้างเคียงกับแอปพลิเคชันอื่น ("เหตุใดจึงมีทริกเกอร์ที่ไม่จำเป็นดังกล่าว ??!" / "เราไม่ต้องการข้อมูลนั้นอีกต่อไป!") มันยากอยู่แล้วกับฐานข้อมูลเดียวสำหรับแอปพลิเคชันเดียวเมื่อนักพัฒนาไม่สามารถ / ไม่รู้จักการใช้งานทั้งหมด

• การบริหารกลายเป็นหนัก:วัตถุใดเป็นของแอปพลิเคชันใด ความโกลาหลที่เพิ่มขึ้น ฉันต้องค้นหาข้อมูลของฉันที่ไหน ผู้ใช้คนใดที่ได้รับอนุญาตให้โต้ตอบกับวัตถุใด ฉันจะอนุญาตให้ใครได้บ้าง

• การอัปเกรด:คุณจะต้องมีเวอร์ชันที่เป็นตัวหารร่วมที่ต่ำที่สุดสำหรับแอปพลิเคชันทั้งหมดที่ใช้ นั่นหมายความว่าแอปพลิเคชันบางอย่างจะไม่สามารถใช้คุณสมบัติที่มีประสิทธิภาพ คุณจะต้องติดกับรุ่นเก่ากว่า นอกจากนี้ยังเพิ่มต้นทุนการพัฒนาเล็กน้อย

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

เมื่อเปรียบเทียบกับการนำเข้าข้อมูล / กระบวนการ ETL นั้นค่อนข้างตรงไปตรงมาและเรียบง่าย โหลดข้อมูลได้บ่อยเท่าที่คุณต้องการพื้นที่มีราคาถูก คุณสามารถปรับขนาดได้สำหรับแต่ละแอปพลิเคชันอย่างอิสระปรับและปรับแต่งโครงสร้างตามที่คุณต้องการและจะไม่มีปัญหาเกิดขึ้นพร้อมกัน ผลข้างเคียงสามารถติดตามได้ง่ายขึ้นเช่นกัน

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

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

ตัวอย่างเช่นแอปพลิเคชันทั้ง 3 ที่จำเป็นในการทำงานกับข้อมูลพนักงาน ทั้งระบบสินค้าคงคลังและการจัดซื้อจัดจ้างใช้ข้อมูลเดียวกันของสินค้าและรายการสินค้าคงคลัง

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

ฉันยังสร้าง UI ทั่วไปสำหรับการโต้ตอบกับผู้ใช้และสินค้าซึ่งเป็นแอปพลิเคชันเว็บแยกต่างหากในตัวของมันเอง

ดังนั้นการเพิ่มสิ่งที่ @Falcon ได้ชี้ไปฉันคิดว่าคุณสามารถได้รับประโยชน์จากการรวมศูนย์การทำงานร่วมกันระหว่างแอพพลิเคชั่นในฐานข้อมูลเดียว

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

หากประสิทธิภาพเริ่มเป็นปัญหาให้เรพลิเคท db ไปยังเซิร์ฟเวอร์หลายเครื่องเพื่อสร้างความสมดุล

อาจหรือไม่คุ้มค่ากับการแลกเปลี่ยนในสถานการณ์ของคุณ แต่การรักษาความถูกต้องของข้อมูลนั้นง่ายกว่าด้วยฐานข้อมูลเดียว อย่างน้อยใน MS SQL Server คุณไม่สามารถ foreign key จากฐานข้อมูลหนึ่งไปยังฐานข้อมูลอื่นได้ คุณสามารถจำลองพฤติกรรมต่างประเทศด้วยปุ่มทริกเกอร์ แต่มันก็ไม่ได้ดูสง่า

นอกจากนี้การสร้างสำเนาข้อมูลในเครื่องอาจเป็นอันตรายได้เมื่อมีการเขียนข้อมูล หากทั้ง AppA และ AppB มีสำเนาของข้อมูลที่แชร์และอัปเดต AppA AppB จะยังคงมีข้อมูลเก่าอยู่ หรือคุณจะต้องตั้งค่าทริกเกอร์เพื่อเก็บข้อมูลให้ตรงกัน

เมื่อฉันมีหลายเว็บไซต์ที่ได้รับความนิยมเมื่อเวลาผ่านไป พวกเขาใช้ฐานข้อมูลแยกกันส่วนใหญ่เป็นเพราะผู้ให้บริการพื้นที่อนุญาตให้ 1GB พื้นที่เก็บข้อมูลเท่านั้น แต่! ทันทีที่ฉันเปิดตัวบริการที่รวมเว็บไซต์เหล่านี้ทั้งหมดฉันเริ่มทำธุรกรรมระหว่างเว็บไซต์เหล่านี้และวิธีที่สะดวกที่สุดในการทำเช่นนี้คือการย้ายทุกอย่างไว้ในฐานข้อมูลขนาดใหญ่

ดังนั้นฉันจึงปรับโครงสร้างฐานข้อมูลและบีบอัดส่วนที่เกี่ยวข้องกับฐานข้อมูลกลางนี้ แต่ทิ้งทุกอย่างออกไป

ความคิดเห็นของฉันเกี่ยวข้องกับกระบวนทัศน์ของ OOP ข้อมูลที่คล้ายกันจะต้องจัดเก็บไว้ด้วยกันดังนั้นหากคุณสร้างแอปพลิเคชั่นที่แตกต่างกันคุณควรใช้ฐานข้อมูลที่แตกต่างกัน

ในกรณีข้างต้นการใช้ db ทั่วไปไม่สามารถหลีกเลี่ยงได้ แต่โปรดจำไว้ว่าฉันยังแยกตารางบางส่วนออกจากฐานข้อมูลแยกต่างหากซึ่งไม่ใช่ส่วนหนึ่งของแบบสอบถามทั่วไป

ยิ่งไปกว่านั้นถ้าคุณแยกพวกมันออกจากกันมันจะง่ายกว่าในการสำรองข้อมูลซึ่งจะมีโอกาสน้อยที่ข้อมูลจะสูญหาย หากมีสิ่งใดผิดพลาดและแอปพลิเคชันรบกวนซึ่งกันและกันฐานข้อมูลจะทำให้เกิดความยุ่งเหยิงและโดยทั่วไปคุณไม่ต้องการเปิดเผยแอปของคุณถึงอันตรายนี้

สรุปคุณสามารถรักษาฐานข้อมูลทั่วไปสำหรับการสืบค้นทั่วไป แต่ยังเก็บไว้ในฐานข้อมูลสำหรับแต่ละแอปพลิเคชันของคุณ

คุณสามารถอธิบายเพิ่มเติมเกี่ยวกับสถาปัตยกรรมแอปพลิเคชันของคุณได้หรือไม่?

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