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

13

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

จะเป็นการดีกว่าหรือไม่ที่จะลบUsersตารางออกจากฐานข้อมูล 2 และ 3 และแทนที่ด้วยSynonymจุดนั้นไปยังฐานข้อมูล 1

นี่คือข้อดีข้อเสียที่ฉันคิดได้:

ข้อดี

บำรุงรักษาง่ายขึ้น สามารถอัปเดตผู้ใช้ในที่เดียวแทนที่จะเป็น 3
รหัสผู้ใช้จะจับคู่ระหว่างฐานข้อมูล (สำคัญเนื่องจากแอปเสริมจำนวนมากอิงตามรหัสผู้ใช้)

จุดด้อย

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

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

sql-server database-design

— ราเชล
แหล่งที่มา

3

มันจะเหมาะสมกว่าไหมถ้ามีสคริปต์เพื่อซิงโครไนซ์ / ผสานความแตกต่างระหว่างสคริปต์เหล่านั้น? ฉันเองไม่ชอบการสร้าง 2 ฐานข้อมูลขึ้นอยู่กับหนึ่งในสามเพราะคำเหมือนเช่นนี้

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner ดูเหมือนว่าจะทำงานได้มากกว่าและยากที่จะรวมการเปลี่ยนแปลงในฟิลด์ที่สร้างโดยอัตโนมัติเช่นคีย์หลัก

— Rachel

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

— FrustratedWithFormsDesigner

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

— Rachel

6

ทำไมคุณมี 3 ฐานข้อมูลกับผู้ใช้เดียวกัน

จะเกิดอะไรขึ้นถ้าฐานข้อมูลเดียวล้มเหลว?

ฉันถามคำถามเหล่านี้เพราะคอนของฐานข้อมูลผู้ใช้ที่ลงมาป้องกันการใช้อีกสองฐานข้อมูลอาจไม่เป็นปัญหาใหญ่เท่าที่ฟัง

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

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

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

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

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

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

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

— ErikE
แหล่งที่มา

3

มี "คอน" ที่หายไป

ในการกู้คืนเป็นไปได้ว่าผู้ใช้ของคุณจะไม่มีอยู่ในฐานข้อมูลเป้าหมาย (ของคำเหมือน) บอกว่ามันเสียหายและคุณต้องกู้คืนจากข้อมูลสำรอง

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

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

ดังนั้นอย่าทำ ...

คำตอบที่เกี่ยวข้องกับ dba.se: เกณฑ์การตัดสินใจว่าเมื่อใดควรใช้ schema ที่ไม่ใช่ dbo เทียบกับฐานข้อมูลใหม่เกี่ยวกับ "integrity referential cross-database" หลังจากเรียกคืน

— GBN
แหล่งที่มา

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

— ราเชล

1

@Rachel: ไม่สามารถมีตารางเป้าหมายได้ แต่ข้อมูลอาจเก่ากว่า ดังนั้นเมื่อคุณกู้คืนคุณจะมีผู้ใช้ที่ขาดหายไป ... ลิงก์เกี่ยวกับ "ความสมบูรณ์ของการอ้างอิงข้ามฐานข้อมูล"

— gbn

2

อีกทางเลือกหนึ่งคือการลบตารางในฐานข้อมูล 2 และ 3 และแทนที่ด้วยมุมมอง materializedของตารางในฐานข้อมูล 1

ข้อดี

การบำรุงรักษาง่ายขึ้น (จากข้อมูล)
รหัสการจับคู่
ไฟดับไม่ส่งผลกระทบต่อฐานข้อมูลอื่น (อย่างน้อยก็จนกว่าจะต้องมีการเปลี่ยนแปลง)
ฐานข้อมูลใด ๆ ที่สามารถใช้ในการกู้คืนตาราง

จุดด้อย

ข้อมูลเป็นข้อมูลล่าสุดตามกำหนดเวลาการรีเฟรชของคุณเท่านั้น
หากคำจำกัดความตารางเปลี่ยนแปลงมุมมองที่ปรากฏขึ้นอาจจำเป็นต้องเปลี่ยนแปลงเช่นกัน

นอกจากนี้โปรดทราบว่าขึ้นอยู่กับความถี่ของการค้นหาความถี่ของการรีเฟรชและความถี่ของการเปลี่ยนแปลงข้อมูลสิ่งนี้อาจหรืออาจไม่แนะนำการโหลดมากกว่าโซลูชันคำเหมือน

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

— Leigh Riffel
แหล่งที่มา

1

คุณไม่สามารถทำให้มุมมองเป็นรูปเป็นร่าง (มุมมองที่จัดทำดัชนีไว้ที่นี่) cross-db ใน SQL Server + พวกเขาไม่ต้องการรีเฟรช: พวกเขาเป็น "เรียลไทม์"

— gbn

@gbn โพสต์ของฉันถูกเขียนก่อนเพิ่มแท็ก SQL Server

— Leigh Riffel

ฉันเพิ่มแท็กขึ้นอยู่กับคำตอบของคุณ :)

— ราเชล

1

ฉันจะสร้างฐานข้อมูลที่ 4 ที่เก็บข้อมูลผู้ใช้ที่แชร์ สร้างSynonymsหรือViewsในแต่ละ Dbs อื่น ๆ ที่ชี้ไปยังฐานข้อมูลผู้ใช้

สุดท้ายฉันจะสร้างตารางส่วนขยาย (ตารางที่มีความสัมพันธ์แบบหนึ่งเดียวกับ 'UserDB.Usertable') ใน 3 dbs ที่มีอยู่แต่ละรายการที่เก็บข้อมูลผู้ใช้เฉพาะแอปนั้น

แก้ไข: ขึ้นอยู่กับความคิดเห็นด้านล่าง

ในกรณีนั้นให้ทำการ db แรกทำหน้าที่เป็นตารางผู้ใช้หลัก Synonymsและตารางส่วนขยายใน Other Dbs แต่ละรายการ

หมายเหตุสำคัญ : ด้วยวิธีการนี้หากแอปแรกของคุณหยุดทำงานอีกสองแอปจะถูกดึงลงมาด้วย! ตรวจสอบให้แน่ใจว่าทุกคนเข้าใจข้อเสียนี้

— ซ
แหล่งที่มา

น่าเศร้าที่ไม่ใช่ตัวเลือกสำหรับฉัน มันจะเป็นตัวเลือกที่ฉันชอบถ้าฉันออกแบบบางอย่างตั้งแต่เริ่มต้น แต่ในกรณีนี้ฉันกำลังทำงานกับระบบที่มีอยู่แล้ว ในกรณีของฉันเรามีฐานข้อมูล 1 ซึ่งมีอยู่เป็นเวลาหลายปีและเพิ่งเพิ่มฐานข้อมูล 2 และ 3

— Rachel

เหตุใดจึงสามารถลบตารางและชี้ไปที่คำพ้องความหมายไปที่ db แรก แต่ไม่ใช่ไปที่ใหม่

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

— Rachel

ฉันเห็นการแก้ไขของคุณ ... นั่นคือสิ่งที่ฉันพยายามทำ แต่คำถามของฉันคือนี่เป็นความคิดที่ดีหรือไม่และถ้าไม่ทำไม?

— Rachel

ทุกอย่างปกติดี. หากคุณตกลงที่จะทำให้แอพข่าวทั้ง 2 แอพขึ้นอยู่กับแอพแรก