การรวบรวมข้อมูลจากตารางที่แตกต่างกันเป็นแบบฝึกหัดหรือไม่

พื้นหลัง

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

ปัญหา

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

"ทางออก" ของฉัน

แผนของฉันคือการเขียนระเบียนทั้งหมดเหล่านี้ลงในตาราง "catch-all" หนึ่งตารางและเขียนทริกเกอร์บนตารางดั้งเดิมเพื่อรักษาระเบียนในตารางรวมนี้ แน่นอนฉันต้องมั่นใจว่าตัวกระตุ้นของฉันยังคงอยู่หลังจากการอัพเดต แต่จะง่ายกว่ามากจากมุมมองการบำรุงรักษาและเพียงแค่อ้างอิงข้อมูล

ตารางจะบางและยาวเก็บเฉพาะข้อมูลที่ต้องการเช่นนี้:

CREATE TABLE dbo.HCM_Event_Log (
    id INT IDENTITY,
    type_id INT NULL,
    orig_id VARCHAR(36) NULL,
    patient_id UNIQUEIDENTIFIER NOT NULL,
    visit_id UNIQUEIDENTIFIER NULL,
    lookup_id VARCHAR(50) NULL,
    status VARCHAR(15) NULL,
    ordered_datetime DATETIME NULL,
    completed_datetime DATETIME NULL,
    CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id)
)

จากนั้นฉันก็จะมีตารางที่สัมพันธ์กันหลายอย่างสำหรับสิ่งต่าง ๆ เช่นกลุ่ม type_id และรายการ

ฉันเริ่มที่จะเดาความคิดที่สองเนื่องจากตารางเหล่านี้เขียนขึ้นมาไม่มากนัก SP และรายงานที่ฉันกำลังเขียนจะอ้างอิงข้อมูลมากเช่นกัน ดังนั้นฉันกังวลว่าตารางนี้จะกลายเป็นการล็อกระเบียนและฝันร้ายของการแสดงด้วย I / O มากมาย

คำถามของฉัน

เป็นความคิดที่ดีหรือไม่ดี? ฉันรู้ว่าทุกสถานการณ์แตกต่างกันใน SQL Server (2008 r2 Standard Edition BTW) และกฎ "บางครั้ง" แต่ฉันแค่มองหาคำแนะนำทั่วไป

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

ถ้าฉันเข้าใจคุณถูกต้อง

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

ฉันจะเข้าใกล้มันเช่นนี้:

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

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

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

ดังนั้นประเด็นหลักคือ - แยกและ จำกัด ส่วนของระบบของคุณที่ขึ้นอยู่กับ internals ของระบบบุคคลที่สาม

ปรับปรุง

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

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

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

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

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

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

อย่างที่คนอื่น ๆ พูดถึงอย่าใช้ทริกเกอร์ซิงค์เป็นกลุ่ม

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

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

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

ในด้านบวก:

1. "เรียลไทม์" ถูก จำกัด เฉพาะกับเครือข่ายและการทำธุรกรรมกระทำประสิทธิภาพในการสมัครสมาชิก จากประสบการณ์ของฉันกับระบบ TPS ระดับสูงเราได้รับการจำลองแบบภายในเวลาไม่ถึง 10 วินาทีของข้อมูล "เรียลไทม์"
2. การแยกเวิร์กโหลด คุณกำลังเรียกใช้งานเวิร์กโหลดแบบผสมบนเซิร์ฟเวอร์เดียว หากคุณสามารถแยกข้อกังวลสองข้อนี้ออกจากกันคุณอาจได้รับประโยชน์ด้านประสิทธิภาพการทำงานของทั้งสองระบบในการลบภาระงานหนึ่งอันออกจากสมการ
3. ควบคุม. คุณจะสามารถสร้างดัชนี / สถิติ / การแก้ไขบำรุงรักษาเพื่อให้เหมาะกับภาระงานการรายงานของคุณ

มีข้อเสียคือ:

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

แผนของฉันคือการเขียนระเบียนทั้งหมดเหล่านี้ลงในตาราง "catch-all" หนึ่งตารางและเขียนทริกเกอร์บนตารางดั้งเดิมเพื่อรักษาระเบียนในตารางรวมนี้

ทริกเกอร์มีปัญหามากมายที่คุณควรหลีกเลี่ยง:

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

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