V / s เดี่ยวหลายฐานข้อมูล

ฉันได้สร้างเว็บแอปนี้ (php & mysql) ซึ่งเก็บข้อมูลสำหรับองค์กรต่าง ๆ (ปัจจุบันมีลูกค้าประมาณ 20 คน)

สถานการณ์ปัจจุบันเก็บข้อมูลที่เกี่ยวข้องกับลูกค้าในแต่ละฐานข้อมูลดังนั้นจึงมีฐานข้อมูลลูกค้า 20 รายและฐานข้อมูลหลัก 1 ฐาน

หนึ่งในข้อได้เปรียบหลักที่นี่คือเมื่อไคลเอ็นต์ db แต่ละตัวถูกแยกจำนวนของส่วนไคลเอ็นต์ (รายงานการตรวจสอบ) ฯลฯ จะถูกจัดลำดับ ทำให้ลูกค้าของเรารู้สึกถึงความปลอดภัย

แต่ละฐานข้อมูลมีประมาณ 15 ตารางและแถวส่วนใหญ่ในตารางมีประมาณ 2000 รายการซึ่งคาดว่าจะมีการชนกันมากถึง 5,000 ระเบียน

การจัดการการเปลี่ยนแปลงระดับฐานข้อมูลเดียวหมายถึงการเปลี่ยนแปลงฐานข้อมูล 20 รายการ แต่ในเหตุการณ์ที่หายากที่ฉันต้องการทำการเปลี่ยนแปลงดังกล่าวฉันใช้สคริปต์ที่ทำสิ่งนี้ในการเรียกใช้ฟังก์ชันเดียว

เราอยู่ในการจัดการโฮสต์สำหรับที่ใช้ร่วมกันและ ISP ของเราให้บริการเราด้วยจำนวนที่ จำกัด ของฐานข้อมูล และนั่นคือสิ่งที่ทำให้ฉันคิดในแง่ของการรวมศูนย์ฐานข้อมูล เพื่อให้สามารถเก็บข้อมูลไคลเอ็นต์ทั้งหมดในฐานข้อมูลหลัก

แน่นอนว่าประเด็นสำคัญบางอย่างที่เกิดขึ้น ได้แก่ :

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

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

คุณคิดว่าการย้ายไปยังฐานข้อมูลส่วนกลางทำให้รู้สึกมากกว่าอยู่อย่างที่เราเป็น

ขอบคุณสำหรับคำแนะนำ.

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

โปรของฐานข้อมูลเดียว:

1. การอัพเดตซอฟต์แวร์และการแก้ไขข้อผิดพลาดนั้นง่ายขึ้น
2. ง่ายต่อการจัดการและรายงานข้อมูลลูกค้าทั้งหมด
3. การอัปเดตข้อมูลจะง่ายขึ้น
4. ง่ายต่อการสร้างฟังก์ชั่นแบบแยกส่วนที่ไคลเอนต์ 1 ต้องการปิดถ้าปิดสำหรับไคลเอนต์อื่นจากนั้นเปิดหนึ่งเมื่อพวกเขาต้องการในอนาคต

ข้อเสียของฐานข้อมูลเดียว:

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

โปรของหลายฐานข้อมูล:

1. ไม่มีความกังวลเกี่ยวกับการปนเปื้อนหรือการละเมิดข้อมูลลูกค้าข้าม
2. การส่งออกข้อมูลลูกค้าเป็นเรื่องง่าย

ข้อเสียของหลายฐานข้อมูล:

1. อัปเดตและแก้ไขข้อผิดพลาด - นี่คือฝันร้ายที่แท้จริง เมื่อคุณมีลูกค้า 20 รายในฐานข้อมูลที่แตกต่างกัน 20 รายการคุณจะพบกับกรณีที่ลูกค้า 1 รายต้องการแก้ไขบั๊กและอีกคนคิดว่าบั๊กนั้นเป็นคุณสมบัติหรือไม่ต้องการเสี่ยงต่อการอัพเดท นอกจากนี้คุณจะมีอินสแตนซ์ที่ลูกค้า 1 รายต้องการการปรับปรุงการเปลี่ยนแปลงเกม แต่ลูกค้ารายอื่นไม่ต้องการ เมื่อสิ่งนี้เกิดขึ้นฐานข้อมูลของคุณจะเริ่มแตกต่าง ทันใดนั้นคุณจะต้องอัปเดตลูกค้า 1-15 ด้วย 1 สคริปต์ 16-19 กับอีกหนึ่งและ 20 กับหนึ่งในสาม เราเห็นว่าสิ่งนี้กลายเป็นปัญหาที่การแก้ไขข้อผิดพลาดจะใช้เวลา 15 ถึง 20 เท่าสำหรับ บริษัท ที่เราซื้อมากกว่าเพราะเราต้องทำการทดสอบทั้งหมดสำหรับลูกค้าทุกคนและจัดการกับรหัสลูกค้าพิเศษแต่ละราย อย่างมีประสิทธิภาพพวกเขาต้องการคนสนับสนุนใหม่สำหรับลูกค้าใหม่ทุกคน
2. การจัดการฐานข้อมูล - เมื่อคุณเข้าถึงลูกค้าจำนวนมากที่จัดการฐานข้อมูลทั้งหมดจะกลายเป็นเรื่องยุ่งยาก คุณจะไม่ต้องสงสัยเลยว่าต้องใช้เวลา DBA มากขึ้นในการจัดการพวกเขา

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

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

นอกจากนี้ยังหมายความว่าหากมีปัญหากับฐานข้อมูลของลูกค้ารายหนึ่งจะไม่ส่งผลกระทบต่อฐานข้อมูลอื่นทั้งหมด

หากคุณต้องการเปรียบเทียบข้อมูลระหว่างลูกค้าคุณควรทำแยกกัน

หากคุณมีฐานข้อมูลไม่เพียงพอคุณอาจต้องพิจารณาเปลี่ยนผู้ให้บริการโฮสต์ของคุณ

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

แต่นอกเหนือจากกรณีนี้ฉันคิดว่าหลายฐานข้อมูลดีกว่า

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

นอกจากนี้ฐานข้อมูลหลายแห่งยังอนุญาตให้ตารางย่อย (เช่นประเภทโทรศัพท์) สามารถปรับแต่งได้อย่างง่ายดายต่อลูกค้าโดยไม่จำเป็นต้องมีรหัสบันทึกผู้ปกครองในตารางเหล่านี้เช่นกัน

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

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

ลงไปที่ถนนมันง่ายต่อการปรับขนาด (การแบ่งพาร์ติชันฮาร์ดแวร์การแบ่งส่วน ฯลฯ ) ฐานข้อมูลเดียวมากกว่าที่จะทำเช่นเดียวกันสำหรับฐานข้อมูล 100 รายการ

ฉันคิดว่าโปสเตอร์อื่น ๆ ได้ทำคะแนนที่ยอดเยี่ยมดังนั้นฉันจะไม่ไปมากกว่านั้น

ในการเพิ่มโปร / คอนลงในรายการ:

โปรของฐานข้อมูลหลาย:

1. หลีกเลี่ยงปัญหาการล็อค; เรามีฐานข้อมูลที่ลูกค้าสามารถเรียกใช้การเปลี่ยนแปลง DDL ในบางตาราง สำหรับตารางที่มีขนาดใหญ่กว่า (ระเบียน 2m) สิ่งนี้จะล็อคตารางเป็นระยะเวลานานพอสมควร คนที่เสียเปรียบเท่านั้นคือผู้ใช้ของตัวเองดังนั้นนี่จึงเป็นที่ยอมรับได้

2. ความยืดหยุ่น - ลูกค้าบางรายมีความต้องการเฉพาะเกี่ยวกับข้อมูลที่พวกเขาต้องการจัดเก็บ; หลายฐานข้อมูลทำให้เรามีความยืดหยุ่นในการปรับเปลี่ยนฐานข้อมูลของพวกเขาโดยเฉพาะโดยไม่ต้องถ่วงรูปแบบข้อมูลสำหรับลูกค้ารายอื่น

จุดด้อย:

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

ขอให้โชคดีในการเลือก!

ฉันรู้ว่าคุณได้เลือกคำตอบแล้ว แต่ดูเหมือนว่ามีวิธีแก้ไขปัญหาอื่นที่ไม่ได้แนะนำ:

ย้ายทุกอย่างไปยังฐานข้อมูลเดียว แต่สร้างตารางสำหรับลูกค้าแต่ละรายโดยใช้คำนำหน้าเช่นนี้

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

มันเป็นสิ่งที่ดีที่สุดของทั้งสองโลก

• ง่ายมากที่จะโยกย้ายจากการตั้งค่าปัจจุบันของคุณไปยังการตั้งค่าใหม่
• คุณสามารถสร้างผู้ใช้ 1 รายต่อลูกค้าและ จำกัด สิทธิ์ในตารางของ บริษัท และไม่มีอะไรอื่นอีก
• คุณสามารถสร้าง superuser และรวบรวมข้อมูลได้อย่างง่ายดายหากคุณต้องการ
• ใช้ฐานข้อมูลเดียวเท่านั้น