Là chuẩn hóa cơ sở dữ liệu đã chết? [đóng cửa]

Tôi đã được đưa lên trường cũ - nơi chúng tôi đã học cách thiết kế lược đồ cơ sở dữ liệu TRƯỚC KHI lớp kinh doanh của ứng dụng (hoặc sử dụng OOAD cho mọi thứ khác). Tôi đã khá giỏi với việc thiết kế các lược đồ (IMHO :) và chỉ được chuẩn hóa để loại bỏ sự dư thừa không cần thiết nhưng không ảnh hưởng đến tốc độ tức là nếu tham gia là một điểm nhấn hiệu suất, thì sự dư thừa đã được giữ nguyên. Nhưng chủ yếu là không.

Với sự ra đời của một số khung ORM như ActiveRecord của Ruby hoặc ActiveJDBC (và một số khác tôi không thể nhớ, nhưng tôi chắc chắn có rất nhiều) có vẻ như họ thích có khóa thay thế cho mọi bảng ngay cả khi một số có khóa chính như 'email' - phá vỡ 2NF hoàn toàn. Được rồi, tôi hiểu không quá nhiều, nhưng điều đó làm tôi lo lắng (gần như) khi một số ORM này (hoặc lập trình viên) không thừa nhận 1-1 hoặc 1-0 | 1 (tức là 1 đến 0 hoặc 1). Họ quy định rằng sẽ tốt hơn nếu có mọi thứ như một bàn lớn cho dù nó có hàng tấn nulls "hệ thống ngày nay có thể xử lý nó" là nhận xét mà tôi đã nghe thường xuyên hơn.

Tôi đồng ý rằng các hạn chế về bộ nhớ có mối tương quan trực tiếp với chuẩn hóa (cũng có những lợi ích khác :) nhưng trong thời đại ngày nay với bộ nhớ giá rẻ và máy lõi tứ có phải là khái niệm về chuẩn hóa DB chỉ để lại các văn bản? Là các DBA, bạn vẫn thực hành chuẩn hóa thành 3NF (nếu không phải BCNF :)? Có vấn đề gì không? Thiết kế "lược đồ bẩn" có tốt cho các hệ thống sản xuất không? Làm thế nào một người nên làm cho trường hợp "cho" bình thường hóa nếu nó vẫn còn liên quan.

( Lưu ý: Tôi không nói về các lược đồ sao / bông tuyết của datwarhouse có dự phòng như một phần / nhu cầu của thiết kế nhưng các hệ thống thương mại có cơ sở dữ liệu phụ trợ như StackExchange chẳng hạn)

Một lý do để chuẩn hóa là loại bỏ các dị thường sửa đổi dữ liệu
ORM thường không hỗ trợ điều này.

Tôi có nhiều ví dụ về cơ sở dữ liệu do Hibernate thiết kế phá vỡ nguyên tắc này:

• cồng kềnh (chuỗi lặp lại hơn 100 triệu hàng)
• không có bảng tra cứu (xem bên trên)
• không có DRI (ràng buộc, khóa)
• chỉ số cụm varchar
• các bảng liên kết không cần thiết (ví dụ: thi hành 1..0: 1 khi cột FK không thể thực hiện được)

Điều tồi tệ nhất tôi từng thấy là cơ sở dữ liệu MySQL 1TB có lẽ quá lớn 75-80% vì những điều này

Tôi cũng đề nghị rằng tuyên bố "các hệ thống ngày nay có thể xử lý nó" là đúng đối với hầu hết các hệ thống chuột Mickey. Khi bạn mở rộng quy mô, các hệ thống ngày nay sẽ không.

Trong ví dụ của tôi ở trên, không có lực kéo để cấu trúc lại hoặc thay đổi khóa hoặc sửa dữ liệu: chỉ phàn nàn về tốc độ tăng trưởng cơ sở dữ liệu và không có khả năng xây dựng một DW có ý nghĩa trên nó

có vẻ như họ thích có một khóa thay thế cho mọi bảng ngay cả khi một số có các khóa chính như 'email' - phá vỡ hoàn toàn 2NF.

Khóa thay thế không phá vỡ 2NF. 2NF nói "Nếu một cột chỉ phụ thuộc vào một phần của khóa đa giá trị, hãy xóa cột đó sang một bảng riêng biệt."

Họ quy định rằng sẽ tốt hơn nếu có mọi thứ như một bàn lớn cho dù nó có vô số

Có một số cột trong một bảng là hợp lệ miễn là tuân theo các quy tắc Chuẩn hóa. Sẽ không đúng khi hợp nhất các bảng mà không phân tích nếu bạn muốn gặt hái những lợi ích của SQL và chuẩn hóa.

Tôi đồng ý rằng các hạn chế về bộ nhớ đã có mối tương quan trực tiếp với chuẩn hóa Mối quan hệ Các dạng thông thường là một khái niệm toán học và không liên quan gì đến bộ nhớ.

Bình thường hóa không chỉ để tiết kiệm bộ nhớ hoặc đĩa, nó còn ở đó để thêm tính toàn vẹn. Rốt cuộc nó là một khái niệm toán học độc lập với phần cứng.

Ví dụ đơn giản: Giả sử bạn duy trì thông tin trường học như:

Rec 1: Trường trung học North Ridge, California, Hoa Kỳ

Rec 2: Trường trung học South Toronto Braves, Ontario, Canada

Nếu bạn hỏi hệ thống của bạn ở đâu là Ontario, bạn có thể biết rằng nó ở Canada. Vài ngày sau bạn xóa hàng thứ 2 và hỏi hệ thống câu hỏi tương tự và bạn không nhận được gì. Trong ví dụ này, không có bao nhiêu dung lượng đĩa hoặc bộ nhớ hoặc CPU, bạn sẽ không nhận được câu trả lời.

Đây là một trong những quan hệ bình thường hóa bất thường giúp ngăn ngừa.

Chỉnh sửa: Thay đổi từ Toronto thành Ontario theo nhận xét bên dưới.

Càng nhiều thứ thay đổi, họ càng giữ nguyên. Luôn luôn có những nhà phát triển lười biếng cắt giảm góc hoặc chỉ không biết hoặc muốn làm theo các thực tiễn tốt nhất. Rất nhiều thời gian họ có thể thoát khỏi nó trong các ứng dụng nhỏ hơn.

Nó từng gây nhiễu các cấu trúc dữ liệu lấy cảm hứng từ COBOL vào RDBMS ban đầu, hoặc mớ hỗn độn khủng khiếp của Chúa là dBase. Bây giờ là ORM và "Code-First". Cuối cùng, đây chỉ là những cách mọi người cố gắng tìm viên đạn bạc để có được một hệ thống làm việc mà không "lãng phí" thời gian suy nghĩ kỹ về những gì bạn muốn và cần làm. Việc vội vàng luôn là một vấn đề và sẽ luôn là một vấn đề.

Đối với những người có ý thức tốt (và may mắn) dành thời gian để thiết kế đúng cách, mô hình dữ liệu sẽ luôn là nơi hợp lý nhất để bắt đầu. Những gì diễn ra trong cơ sở dữ liệu là thông tin về những thứ (hữu hình và vô hình) mà doanh nghiệp của bạn quan tâm. Những gì doanh nghiệp của bạn quan tâm về những thay đổi nhanh hơn nhiều so với cách doanh nghiệp của bạn hoạt động. Đây là lý do tại sao cơ sở dữ liệu của bạn thường ổn định hơn nhiều so với mã của bạn.

Cơ sở dữ liệu là nền tảng hợp pháp của bất kỳ hệ thống nào và dành thời gian để đặt nền móng của bạn đúng cách chắc chắn sẽ mang lại lợi ích cho bạn trong thời gian dài. Điều đó có nghĩa là chuẩn hóa sẽ luôn là một bước quan trọng, hữu ích cho bất kỳ ứng dụng loại OLTP nào.

Tôi đồng ý rằng các hạn chế về bộ nhớ đã có mối tương quan trực tiếp với bình thường hóa ...

Hạn chế bộ nhớ vẫn còn vấn đề. Số lượng không phải là một vấn đề, tốc độ là.

• CPU không nhận được bất kỳ nhanh hơn tại thời điểm này (Chúng tôi đang nhận được nhiều lõi hơn, không phải chu kỳ mỗi giây)
• Các kiến ​​trúc CPU hiện đại cố gắng vượt qua giới hạn tốc độ bằng cách cung cấp bộ nhớ riêng cho mỗi bộ xử lý ( NUMA ).
• Kích thước bộ đệm khi chết không tăng với tốc độ tương đương với bộ nhớ chính.
• Thông lượng bộ nhớ không cao như hầu hết mọi người mong đợi. QPI nằm trong vùng 25GB / giây.

Một số nền tảng này đã được đề cập trong Khi nào nên sử dụng TINYINT trên INT? mà bạn có thể tìm thấy hữu ích. Tôi cũng đề nghị theo dõi các trò hề của @ThomasKejser ( blog ) từ nhóm SQLCAT, vì chúng có xu hướng vượt trội về hiệu suất cơ sở dữ liệu. Bài đăng gần đây về Hiệu ứng của bộ nhớ CPU và các mẫu truy cập bộ nhớ và bản trình bày SQLBits về Mô hình hóa quan hệ cho quy mô DW cực lớn là những ví dụ điển hình.

Theo tôi, nó vẫn chỉ là về sự cân bằng giữa bình thường hóa và không bình thường hóa . Tôi hoàn toàn đồng ý rằng các khung ORM chỉ là cách tiếp cận để hoàn thành công việc, nhưng tôi không nghĩ rằng chính các khung này gây ra xu hướng không bình thường hóa .

đó vẫn là cuộc tranh luận mà bạn muốn hiệu quả về thời gian hoặc bạn muốn hiệu quả về không gian. Tại thời điểm lý thuyết cơ sở dữ liệu quan hệ được đưa ra, việc lưu trữ đĩa rất tốn kém, mọi người rõ ràng không muốn chi nhiều tiền cho việc này, đó là lý do tại sao vào thời điểm đó, cơ sở dữ liệu quan hệ là người đứng vững giữa những nghịch cảnh

Ngày nay mọi thứ khá khác biệt, lưu trữ rất rất rẻ. Vì vậy, rõ ràng chúng ta có thể chịu đựng được sự dư thừa nhiều hơn so với ngày xưa, đây cũng là lý do TẠI SAO phương pháp BIG_TABLE xuất hiện. để tìm kiếm hiệu quả thời gian nhiều hơn, hiệu quả không gian phải được hy sinh.

Nhưng, cách tiếp cận bảng lớn cũng không phải là kết thúc của câu chuyện, nó vẫn là sự cân bằng giữa thời gian và không gian, về mặt dữ liệu khối lượng PB cần quản lý, một số nhà phát triển cũng bắt đầu tìm kiếm sự cân bằng trở lại hiệu quả không gian, đó là lý do tại sao có là những công việc được thực hiện để bình thường hóa một số dữ liệu trong BIG-TABLE như các cấu trúc.

Nói một cách dễ hiểu, phương pháp bình thường hóa không chắc chắn đã chết, nhưng so với ngày xưa thì nó chắc chắn bị bỏ qua.

Ngày của CJ trả lời câu hỏi của bạn ở đây - video chuẩn hóa (sơ bộ) là miễn phí.

http://shop.oreilly.com/product/0636920025900.do

Câu trả lời ngắn gọn: bình thường hóa là cách làm việc đúng đắn về mặt toán học. Nếu bạn không bình thường hóa đúng cách, mô hình dữ liệu của bạn đơn giản là không chính xác.