Dự đoán lợi thế của việc không chuẩn hóa cơ sở dữ liệu

Tôi luôn được dạy để phấn đấu cho hình thức bình thường hóa cơ sở dữ liệu bình thường cao nhất và chúng tôi được dạy thuật toán Tổng hợp của Bernstein để đạt được 3NF. Điều này rất tốt và thật tuyệt khi bình thường hóa cơ sở dữ liệu của bạn, biết rằng các trường có thể được sửa đổi trong khi vẫn giữ được tính nhất quán.

Tuy nhiên, hiệu suất có thể bị ảnh hưởng. Đó là lý do tại sao tôi tự hỏi liệu có cách nào để dự đoán tốc độ tăng tốc / giảm tốc khi không chuẩn hóa. Bằng cách đó, bạn có thể xây dựng danh sách các tính năng 3NF của FD và sau đó phi chuẩn hóa ít nhất có thể. Tôi tưởng tượng rằng việc không chuẩn hóa quá nhiều sẽ lãng phí không gian và thời gian, bởi vì các đốm khổng lồ bị trùng lặp hoặc do khó duy trì tính nhất quán hơn vì bạn phải cập nhật nhiều trường bằng giao dịch.

Tóm tắt: Đưa ra bộ 3NF FD và một bộ truy vấn, làm cách nào để dự đoán tốc độ tăng / giảm tốc độ không chuẩn hóa? Liên kết đến các giấy tờ đánh giá cao quá.

Bạn sẽ phải biết các luồng dữ liệu giữa các bảng để có thể xem mô hình DB thực hiện như thế nào. Khi bạn đã có, bạn có thể tính toán thay đổi hiệu suất cho việc không chuẩn hóa nhất định (ví dụ: nếu bạn quyết định sao chép dữ liệu)

Một số ước tính sơ bộ có thể được suy luận bằng cách bạn cần bao nhiêu chỉ số mới sau các bước không chuẩn hóa. Mỗi chỉ mục mới phải được cập nhật và truy vấn một cách riêng biệt, điều này sẽ tạo ra hiệu suất đạt được thành công đối với số lượng chỉ mục mới.

Các đốm dữ liệu nhị phân lớn trong mọi trường hợp nên được lưu trữ trong một bảng riêng biệt và không được sao chép xung quanh. Chúng (thường) không được truy vấn nhưng được trả về như một phần của tập kết quả cuối cùng sau một truy vấn đối với một số bảng khác.

Tôi không chắc có bất kỳ nghiên cứu khoa học nào về việc khi không chuẩn hóa có thể giúp ích (IMHO có một sự khác biệt lớn giữa những gì được dạy về chuẩn hóa DB và cách nó hoạt động trong thực tế).

Tuy nhiên, có một số bài viết và mục blog thú vị về điều này _ Jeff Atwood nói về việc bình thường hóa trong blog của mình và có một "câu trả lời" cho anh ta ở khả năng mở rộng cao.

Khi không chuẩn hóa, tôi khuyên bạn nên chú ý đến

• số lượng và loại truy vấn trên một đơn vị thời gian; nếu bạn sử dụng chèn và / hoặc cập nhật nhiều hơn đọc, việc không chuẩn hóa sẽ không giúp ích nhiều.
• tần suất các thông tin trùng lặp sẽ được cập nhật
• các đặc điểm của DBMS bạn sẽ sử dụng
• bao nhiêu lần thông tin được nhân đôi; nếu bạn có cùng thông tin trong 4-5 bảng, có thể nhanh hơn để giữ thông tin đó trong một bảng riêng thay vì sao chép quá nhiều lần
• lượng dữ liệu dự kiến ​​được giữ trong DB; những gì có thể làm việc cho một lượng nhỏ dữ liệu, có thể dẫn đến một thảm họa nếu số lượng hồ sơ tăng lên. Và ngược lại (ý tôi là nguyên tắc KISS và không sửa những gì không bị hỏng).

Tôi tưởng tượng rằng việc không chuẩn hóa quá nhiều sẽ lãng phí không gian và thời gian

Không gian không phải lo lắng trong hầu hết các ứng dụng OLTP dòng doanh nghiệp cỡ trung bình. Vì vậy, hãy để không gian sang một bên. Thời gian và theo thời gian tôi giả sử bạn có nghĩa là hiệu suất của truy vấn, đó là điều thường có thể được tăng cường và không gây ra vấn đề thực sự trừ khi bạn có thiết kế xấu, không đủ tài nguyên, cơ sở dữ liệu cực lớn, số lượng giao dịch rất lớn hoặc tất cả ở trên. Hầu hết các ứng dụng sử dụng cơ sở dữ liệu ngày nay hiếm khi gặp vấn đề về hiệu năng chỉ vì cơ sở dữ liệu được Chuẩn hóa.

đốm khổng lồ được nhân đôi hoặc vì khó duy trì tính nhất quán vì bạn phải cập nhật nhiều trường bằng giao dịch.

Bình thường hóa cơ sở dữ liệu của bạn đảm bảo với bạn rằng bạn thiết kế sẽ:

1. Không có dữ liệu dư thừa.

2. Không gây ra số lượng lớn bệnh viêm ruột đăng nhập (ví dụ: có 2 triệu khách hàng: CẬP NHẬT Đặt khách hàng Quốc gia = "Hoa Kỳ" WHERE Country = "US")

3. Được hỗ trợ đầy đủ là Truy vấn SQL. Điểm này rất quan trọng.

4. Sẽ lái mã ứng dụng sạch.

5. Buộc một mức độ cao nhất quán dữ liệu thông qua cơ sở dữ liệu mà không làm gánh nặng ứng dụng.

6. Chia sẻ các quy tắc kinh doanh được xác định trong cơ sở dữ liệu bởi các ứng dụng khác nhau mà không cần mã hóa cùng một mã trong các ứng dụng khác nhau.

Phải nói rằng, Chuẩn hóa tạo ra cấu trúc tối ưu cho tất cả các cột và bảng. Điều này có thể không phải lúc nào bạn cũng cần trong ứng dụng cụ thể của mình, sau đó bạn có thể xác định, dựa trên sự hiểu biết về tên miền và ứng dụng của bạn, để bình thường hóa một số bảng / cột như một sự đánh đổi tốc độ. Tuy nhiên, đó sẽ là một quyết định có ý thức hơn là một sự giám sát.

Đưa ra bộ 3NF FD và một bộ truy vấn, làm cách nào để dự đoán tốc độ giảm tốc độ / bình thường hóa?

Bạn không thể dự đoán chính xác hiệu suất mà không cần kiểm tra (điều bạn có thể làm trước khi viết mã ứng dụng). Tuy nhiên, bạn có thể loại bỏ và phát hiện các yếu tố dẫn đến hiệu suất kém theo thiết kế. Ví dụ: bạn có thể xác định chiến lược chỉ mục nào sẽ sử dụng như sau (các kỹ thuật khác có thể tồn tại):

1. Xây dựng một ma trận các truy vấn và các cột bị ảnh hưởng bởi các truy vấn đó.

2. Tìm các cột được sử dụng nhiều nhất.

3. Xem xét xây dựng các chỉ mục trên các cột.

Đây chủ yếu là một công việc mà DBA của bạn có thể hỗ trợ bạn. Có nhiều hiệu suất hơn bình thường hóa. Có các khía cạnh của phân phối dữ liệu trên khối lượng đĩa, chia bảng dọc, phân vùng, loại chỉ mục và bộ đệm chỉ mục để đặt tên cho một số. Tất cả các kỹ thuật như vậy nên được giải quyết trong sách và tài liệu của nhà cung cấp trong các chủ đề "Thiết kế cơ sở dữ liệu" và "Điều chỉnh hiệu suất cơ sở dữ liệu". Tất cả các cuộc thảo luận ở trên giả định ứng dụng của bạn là một ứng dụng OLTP.

Một trong nhiều lý do chính để bình thường hóa là nó tối ưu hóa cho các trường hợp sử dụng chung trong khi việc không chuẩn hóa có xu hướng tối ưu hóa hiệu suất cho các trường hợp sử dụng chuyên biệt (với các hình phạt đáng kể cho các trường hợp sử dụng khác). Đây là một lý do tại sao khối lượng công việc OLTP thường được hưởng lợi chủ yếu từ việc chuẩn hóa (có những trường hợp ngoại lệ ở đây nhưng chúng rất hiếm).

Để dự đoán lợi thế, những gì bạn thực sự phải biết là chính xác những gì bạn đang không chuẩn hóa và cho những gì quy trình công việc. Cũng có những câu hỏi về kích thước của tập dữ liệu của bạn và tác động của bộ nhớ đệm có thể là gì. Vì vậy, câu trả lời có thể phụ thuộc vào một số lượng rất lớn những thứ bao gồm kích thước cơ sở dữ liệu, phần nào có khả năng vẫn còn trong bộ nhớ, lập kế hoạch chi phí cho các truy vấn phức tạp và tương tự. Đây là một vấn đề rất phức tạp, cụ thể về triển khai và nó phụ thuộc rất nhiều vào cả cơ sở dữ liệu và RDBMS của bạn. Những ưu điểm này sẽ lớn nhất trong khối lượng công việc OLAP và thông thường, nhược điểm sẽ lớn nhất trong khối lượng công việc OLTP.

Vì vậy, tôi không thấy rằng có một câu trả lời duy nhất ở đây ngoài việc xem các kế hoạch truy vấn và xem xét khả năng các chế độ xem được cụ thể hóa cho dữ liệu không chuẩn hóa. Theo quan điểm của tôi, cách tiếp cận tốt nhất là có cơ sở dữ liệu OLTP tương đối chuẩn hóa và không chuẩn hóa cho mục đích báo cáo khi cần thiết.

Thông thường, bạn từ chối bình thường hóa mô hình dữ liệu của mình để tối ưu hóa hiệu suất cho một trường hợp sử dụng cụ thể . Điều này thường sẽ có ảnh hưởng xấu đến hiệu suất của các trường hợp sử dụng khác. ví dụ: lặp lại dữ liệu trong một số hàng có thể tăng tốc xử lý truy vấn bằng cách loại bỏ liên kết, nhưng, quá trình xử lý cập nhật của bạn sẽ bị chậm lại.

Trong thực tế, 3NF cung cấp hiệu suất tối ưu cho bất kỳ số lượng truy cập tùy ý vào cơ sở dữ liệu của bạn, nhưng, đối với các phép nối cụ thể và chọn có thể có một mô hình tốt hơn.

Vì vậy, hãy đối xử với việc không chuẩn hóa như bất kỳ tối ưu hóa nào khác. tức là không làm điều đó trừ khi bạn thực sự có vấn đề về hiệu suất và, hãy đảm bảo rằng 'cách khắc phục' của bạn không gây ra nhiều vấn đề hơn giải quyết.