Lý lịch
Tôi viết rất nhiều báo cáo lớn và thường duy trì một hồ sơ sức khỏe lớn DB (viết SP, chức năng, công việc, v.v.). Lược đồ ban đầu và phần mềm sử dụng nó là của một nhà cung cấp khác, vì vậy tôi không thể thay đổi nhiều về cấu trúc. Có nhiều hồ sơ yêu cầu theo dõi như phòng thí nghiệm, quy trình, vắc-xin, v.v. và chúng nằm rải rác trên hàng chục bảng, nhiều bảng trong số đó bị cồng kềnh và bị lập chỉ mục kém (tôi đã có thể khắc phục điều này).
Vấn đề
Vấn đề là bởi vì chúng tôi có ít quyền kiểm soát DB và vì nó có thể thay đổi từ bất kỳ bản cập nhật hoặc bản vá nào, nên việc viết và duy trì các báo cáo này trở nên khó khăn và tẻ nhạt - đặc biệt là khi có số lượng chồng chéo lớn. Tất cả chỉ là một bản vá và tôi bị mắc kẹt khi viết lại phần lớn của một tá báo cáo. Ngoài ra, các truy vấn nhanh chóng bị xáo trộn và chậm chạp khi tham gia, chọn lồng nhau và áp dụng chồng chất.
Giải pháp của tôi"
Kế hoạch của tôi là viết tất cả các bản ghi này vào một bảng "bắt tất cả" và viết các trình kích hoạt trên các bảng gốc để duy trì các bản ghi trong bảng tổng hợp này. Tất nhiên tôi cần đảm bảo các kích hoạt của mình vẫn còn nguyên vẹn sau khi cập nhật, nhưng điều này sẽ dễ dàng hơn nhiều từ quan điểm bảo trì và chỉ cần tham khảo dữ liệu.
Bảng sẽ mỏng và dài, chỉ lưu trữ dữ liệu cần thiết, đại loại như thế này:
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)
)Sau đó, tôi sẽ có các bảng quan hệ khác nhau cho những thứ như nhóm type_id và nhóm mục.
Tôi bắt đầu đoán thứ hai về ý tưởng này vì một vài trong số các bảng này được viết khá nhiều, các SP và báo cáo tôi sẽ viết cũng sẽ tham chiếu dữ liệu rất nhiều. Vì vậy, tôi lo ngại rằng bảng này sẽ trở thành một cơn ác mộng về hiệu suất và khóa kỷ lục với rất nhiều I / O.
Câu hỏi của tôi
Là một ý tưởng xấu hay tốt? Tôi nhận thấy mọi tình huống đều khác nhau trong SQL Server (2008 r2 Phiên bản tiêu chuẩn BTW) và quy tắc "đôi khi", nhưng tôi thực sự chỉ tìm kiếm lời khuyên chung.
Tôi bắt đầu xem xét sử dụng một nhà môi giới dịch vụ, nhưng tôi chỉ thực hiện các cập nhật / chèn đơn giản ( Xem phần thay thế cho câu trả lời được chấp nhận ). Dữ liệu trong nhiều trường hợp cần phải là thời gian thực, vì vậy sử dụng DB dự phòng sẽ không thực sự hiệu quả. Hiệu suất đã là một vấn đề đối với chúng tôi, nhưng hầu hết đó là liên quan đến phần cứng sẽ sớm được giải quyết.