một bảng cố định có nhiều cột so với bảng trừu tượng linh hoạt

Một số vấn đề cần được làm rõ và giải quyết trước chúng ta có thể tham gia vào một cuộc thảo luận hợp lý.

Giải pháp tiên quyết

1. Nhãn
   Trong một công việc đòi hỏi sự chính xác, điều quan trọng là chúng ta phải sử dụng các nhãn chính xác, để tránh nhầm lẫn và để chúng ta có thể giao tiếp mà không cần phải sử dụng các mô tả và định tính dài dòng.

   Những gì bạn đã đăng dưới dạng FixedTables, là Không chuẩn hóa . Công bằng mà nói, nó có thể là một nỗ lực ở dạng Third Normal, nhưng trên thực tế nó là một tệp phẳng, Unnormalised (không phải "không chuẩn hóa). Những gì bạn đã đăng dưới dạng AbstractTables, chính xác là Thực thể-Thuộc tính-Giá trị , gần như, nhưng không hoàn toàn, dạng Chuẩn thứ sáu, và do đó được Chuẩn hóa nhiều hơn 3NF. Tất nhiên, giả sử nó được thực hiện một cách chính xác.

   • Tệp phẳng không chuẩn hóa không phải là "không chuẩn hóa". Nó chứa đầy sự trùng lặp (không có gì được thực hiện để loại bỏ các nhóm lặp lại và các cột trùng lặp hoặc để giải quyết các phần phụ thuộc) và Nulls, nó là một yếu tố hiệu suất theo nhiều cách và ngăn cản sự đồng thời.

   • Để được Chuẩn hóa, trước tiên nó phải được Chuẩn hóa, và sau đó Chuẩn hóa bị lùi lại một chút vì một số lý do chính đáng. Vì nó không được Chuẩn hóa ngay từ đầu nên nó không thể được Chuẩn hóa. Nó chỉ đơn giản là không chuẩn bị.

   • Nó không thể được cho là không chuẩn hóa "cho hiệu suất", bởi vì là một con lợn biểu diễn, nó là phản nghĩa của hiệu suất. Chà, họ cần một lời biện minh cho việc thiếu thiết kế chính thức], và "vì hiệu suất" là vậy. Ngay cả việc giám sát chính thức nhỏ nhất cũng cho thấy sự trình bày sai lệch (nhưng rất ít người có thể cung cấp, vì vậy nó vẫn bị che giấu, cho đến khi họ có người ngoài giải quyết, bạn đoán nó, vấn đề hiệu suất lớn).

   • Cấu trúc chuẩn hóa hoạt động tốt hơn nhiều so với cấu trúc không chuẩn hóa. Các cấu trúc chuẩn hóa hơn (EAV / 6NF) hoạt động tốt hơn các cấu trúc ít chuẩn hóa hơn (3NF / 5NF).

   • Tôi đồng ý với lực đẩy của Ngựa non OMG, nhưng không đồng ý với nhãn và định nghĩa của chúng

   • chứ không phải nói ' đừng "làm mất chuẩn mực" trừ khi bạn phải' , Tôi đang nói, 'Bình thường hóa một cách trung thực, theo chu kỳ' và 'nếu có vấn đề về hiệu suất, nghĩa là bạn chưa Chuẩn hóa chính xác' .

2. Wikipedia
   Các mục nhập cho Biểu mẫu Thông thường và Chuẩn hóa đưa ra các định nghĩa không chính xác; họ nhầm lẫn giữa các Hình thức Thông thường; chúng còn thiếu liên quan đến quá trình Bình thường hóa; và chúng có trọng số tương đương với các NF vô lý hoặc đáng nghi vấn đã được bóc trần từ lâu. Kết quả là, Wikipedia thêm vào một chủ đề vốn đã khó hiểu và hiếm khi được hiểu. Vì vậy, đừng lãng phí thời gian của bạn.

   Tuy nhiên, để tiến triển mà không có tham chiếu đó gây trở ngại, hãy để tôi nói điều này.

   • Định nghĩa của 3NF là ổn định và không thay đổi.
   • Có nhiều sự nhầm lẫn giữa các NF giữa 3NF và 5NF. Sự thật là đây là một lĩnh vực đã phát triển trong 15 năm qua; và nhiều tổ chức, học giả cũng như các nhà cung cấp sản phẩm của họ có những hạn chế, đã nhảy vào tạo một "Dạng thông thường" mới để xác thực các dịch vụ của họ. Tất cả đều phục vụ lợi ích thương mại và không đáng tin cậy về mặt học thuật. 3NF ở trạng thái ban đầu chưa được đánh giá dự kiến ​​và đảm bảo các thuộc tính nhất định.
   • Tổng số tiền là, 5NF là ngày hôm nay, 3NF dự định là 15 năm trước và bạn có thể bỏ qua lời nói đùa thương mại và mười hai NF "đặc biệt" (thương mại và giả học thuật) ở giữa, một số trong số đó được xác định trong Wikipedia và thậm chí là bằng các thuật ngữ khó hiểu.

3. Biểu mẫu thông thường thứ năm
   Vì bạn đã có thể hiểu và triển khai EAV trong bài đăng của mình, bạn sẽ không gặp vấn đề gì khi hiểu những điều sau. Tất nhiên, một Mô hình quan hệ thực sự là điều kiện tiên quyết, các khóa mạnh, v.v. Dạng chuẩn thứ năm là, vì chúng ta đang bỏ qua Mô hình thứ tư:

   • Biểu mẫu Bình thường Thứ ba
     • theo thuật ngữ đơn giản cuối cùng là, mọi cột không phải khóa trong mỗi bảng đều có mối quan hệ 1 ::1 với Khóa chính của bảng,
     • và không có các cột không phải khóa khác
   • Không trùng lặp dữ liệu (kết quả, nếu Quá trình chuẩn hóa được tiến hành một cách siêng năng; không đạt được chỉ bằng trí tuệ hoặc kinh nghiệm hoặc bằng cách hướng tới mục tiêu mà không cần quy trình chính thức)
   • không có Điểm bất thường về Cập nhật (khi bạn cập nhật một cột ở một nơi nào đó, bạn không phải cập nhật cùng một cột nằm ở một nơi khác; cột tồn tại ở một và chỉ một nơi).
   • Nếu bạn hiểu những điều trên, 4NF, BCNF và tất cả các "NF" ngớ ngẩn có thể bị loại bỏ, chúng là bắt buộc đối với Hệ thống lưu trữ hồ sơ vật lý, như được các học giả quảng bá, khá xa lạ với Mô hình quan hệ (Codd).

4. Biểu mẫu thông thường thứ sáu

   • Mục đích là loại bỏ dữ liệu bị thiếu (cột thuộc tính), hay còn gọi là loại bỏ Nulls
   • Đây là một giải pháp đúng cho vấn đề Null (còn được gọi là Xử lý các giá trị bị thiếu) và kết quả là một cơ sở dữ liệu không có Null. (Nó có thể được thực hiện ở 5NF với các tiêu chuẩn và các sản phẩm thay thế Null nhưng điều đó không phải là tối ưu.) Cách bạn giải thích và hiển thị các giá trị còn thiếu là một câu chuyện khác.
   • Về mặt kỹ thuật, đây không phải là một Dạng chuẩn thực sự, vì nó không có 5NF như một điều kiện tiên quyết, nhưng nó có một giá trị

5. EAV so với Dạng thường thứ sáu
   Tất cả các cơ sở dữ liệu tôi đã viết, ngoại trừ một, là 5NF thuần túy. Tôi đã làm việc với (quản lý, sửa chữa, nâng cao) một vài cơ sở dữ liệu EAV và tôi đã triển khai nhiều cơ sở dữ liệu 6NF thực sự. EAV là một triển khai lỏng lẻo của 6NF, thường được thực hiện bởi những người không hiểu rõ về Chuẩn hóa và NF, nhưng những người có thể nhìn thấy giá trị và cần sự linh hoạt của EAV. Bạn là một ví dụ hoàn hảo.

   Sự khác biệt ở đây là:bởi vì nó lỏng lẻo và bởi vì những người triển khai không có tham chiếu (6NF) để trung thành, họ chỉ triển khai những gì họ cần và họ viết tất cả trong mã; cuối cùng trở thành một mô hình không nhất quán.

   Trong khi đó, triển khai 6NF thuần túy không có điểm tham chiếu học thuật thuần túy, và do đó nó thường chặt chẽ hơn và nhất quán. Thông thường, điều này hiển thị trong hai phần tử hiển thị:

   • 6NF có một danh mục để chứa siêu dữ liệu và mọi thứ được xác định trong siêu dữ liệu, không phải mã. EAV không có, mọi thứ đều nằm trong mã (người triển khai theo dõi các đối tượng và thuộc tính). Rõ ràng là một danh mục giúp giảm bớt việc thêm cột, điều hướng và cho phép hình thành các tiện ích.
   • 6NF khi được hiểu, cung cấp giải pháp thực sự cho Vấn đề Không. Người triển khai EAV, vì họ không có ngữ cảnh 6NF, xử lý dữ liệu bị thiếu trong mã, không nhất quán, hoặc tệ hơn, cho phép Null trong cơ sở dữ liệu. Những người triển khai 6NF không cho phép Null và xử lý Dữ liệu bị thiếu một cách nhất quán và trang nhã mà không yêu cầu cấu trúc mã (để xử lý Null; tất nhiên bạn vẫn phải viết mã cho dữ liệu bị thiếu).

Ví dụ. Đối với cơ sở dữ liệu 6NF có danh mục, tôi có một tập hợp các procs sẽ [lại] tạo SQL cần thiết để thực hiện tất cả các CHỌN và tôi cung cấp Chế độ xem trong 5NF cho tất cả người dùng, vì vậy họ không cần biết hoặc hiểu cấu trúc 6NF cơ bản . Họ bị đuổi khỏi danh mục. Do đó các thay đổi rất dễ dàng và tự động. Các loại EAV thực hiện điều đó theo cách thủ công do không có danh mục.

Thảo luận

Bây giờ, chúng ta có thể bắt đầu thảo luận.

"Tất nhiên có thể trừu tượng hơn nếu giá trị của giá trị được xác định trước (Ví dụ:các chuyên ngành có thể có danh sách riêng)"

Chắc chắn. Nhưng đừng nhận quá "trừu tượng". Duy trì tính nhất quán và triển khai các danh sách như vậy theo cùng một cách thức EAV (hoặc 6NF) như các danh sách khác.

"Nếu tôi sử dụng phương pháp trừu tượng, nó có thể rất linh hoạt, nhưng các truy vấn sẽ phức tạp hơn với nhiều phép nối. Nhưng tôi không biết liệu điều này có ảnh hưởng đến hiệu suất hay không, việc thực thi các truy vấn 'morecomplex' này."

1. Tham gia là người đi bộ trong cơ sở dữ liệu quan hệ. Vấn đề không phải là cơ sở dữ liệu, vấn đề là SQL cồng kềnh khi xử lý các phép nối, đặc biệt là các khóa ghép.

2. Cơ sở dữ liệu EAV và 6NF có nhiều Tham gia hơn, giống như người đi bộ, không hơn, không kém. Nếu bạn phải viết mã từng CHỌN theo cách thủ công, chắc chắn, sự rườm rà sẽ trở nên thực sự cồng kềnh.

3. Toàn bộ vấn đề có thể được loại bỏ bằng cách (a) sử dụng 6NF qua EAV và (b) triển khai một danh mục, từ đó bạn có thể (c) tạo ra tất cả các SQL cơ bản. Loại bỏ toàn bộ lớp lỗi.

4. Đó là một lầm tưởng phổ biến rằng Tham gia bằng cách nào đó có một cái giá phải trả. Hoàn toàn sai.

   • Kết hợp được triển khai tại thời điểm biên dịch, không có gì liên quan đến 'chi phí' cho các chu kỳ CPU.
   • Vấn đề là kích thước của bảng được tham gia, không phải chi phí của việc Tham gia giữa các bảng đó.
   • Kết hợp hai bảng với hàng triệu hàng mỗi bảng, trên một quan hệ PK⇢FK chính xác, mỗi bảng có các chỉ số thích hợp
     (Duy nhất ở phía cha [PK]; Duy nhất ở phía Con [PK =parent FK + cái gì đó]
     là tức thì
   • Trường hợp chỉ mục Con không phải là duy nhất, nhưng ít nhất các cột đứng đầu hợp lệ, thì chỉ mục này chậm hơn; khi không có chỉ mục hữu ích, tất nhiên là nó rất chậm.
   • Không liên quan đến chi phí tham gia.
   • Trường hợp nhiều hàng được trả về, nút cổ chai sẽ là mạng và cách bố trí đĩa; không phải là quá trình tham gia.

5. Vì vậy, bạn có thể nhận được "phức tạp" như bạn muốn, không có chi phí, SQL có thể xử lý nó.

Tôi muốn biết mặt trái của cả hai phương pháp là gì. Tôi có thể tự tưởng tượng, nhưng tôi không có kinh nghiệm để xác nhận điều này.

1. 5NF (hoặc 3NF cho những người không đạt được tiến bộ) là dễ nhất và tốt nhất, về mặt thực hiện; dễ sử dụng (nhà phát triển cũng như người dùng); và bảo trì.

   • Hạn chế là, mỗi khi bạn thêm một cột, bạn phải thay đổi cấu trúc cơ sở dữ liệu (bảng DDL). Điều đó là tốt trong một số trường hợp, nhưng không phải trong hầu hết các trường hợp, do kiểm soát thay đổi tại chỗ, khá phức tạp.
   • Thứ hai, bạn phải thay đổi mã hiện có (mã xử lý cột mới không được tính, vì đó là điều bắt buộc):nơi các tiêu chuẩn tốt được thực hiện, điều đó được giảm thiểu; nơi họ vắng mặt, phạm vi không thể đoán trước được.

2. EAV (là những gì bạn đã đăng), cho phép thêm các cột mà không cần thay đổi DDL. Đó là lý do duy nhất mà mọi người chọn nó. (mã xử lý cột mới không được tính, vì đó là mệnh lệnh). Nếu được triển khai tốt, nó sẽ không ảnh hưởng đến mã hiện có; nếu không, nó sẽ.

3. Nhưng bạn cần những nhà phát triển có khả năng EAV.

   • Khi EAV được triển khai không tốt, điều đó thật đáng ghê tởm, một mớ hỗn độn còn tệ hơn 5NF được thực hiện một cách tệ hại, nhưng không tệ hơn bất kỳ điều gì tồi tệ hơn Unnormalised là điều mà hầu hết các cơ sở dữ liệu hiện có (bị hiểu sai là "không chuẩn hóa cho hiệu suất").
   • Tất nhiên, điều quan trọng hơn (so với 5NF / 3NF) là giữ một ngữ cảnh Giao dịch mạnh mẽ, vì các cột được phân phối nhiều hơn.
   • Tương tự như vậy, điều cần thiết là phải duy trì Tính toàn vẹn tham chiếu trong khai báo:những sai sót mà tôi đã thấy phần lớn là do các nhà phát triển loại bỏ DRI vì nó trở nên "quá khó để duy trì", kết quả là, như bạn có thể tưởng tượng, một mẹ của một đống dữ liệu với các hàng và cột 3NF / 5NF trùng lặp ở khắp nơi. Và xử lý Null không nhất quán.

4. Không có sự khác biệt về hiệu suất, giả sử rằng máy chủ đã được cấu hình hợp lý cho mục đích đã định. (Ok, có những cách tối ưu cụ thể chỉ có thể thực hiện được trong 6NF, điều này không thể thực hiện được trong các NF khác, nhưng tôi nghĩ rằng điều đó nằm ngoài phạm vi của chủ đề này.) Và một lần nữa, EAV được thực hiện không tốt có thể gây ra tắc nghẽn không cần thiết, không hơn thế nữa Không bình thường.

5. Tất nhiên, nếu bạn đi với EAV, tôi khuyên bạn nên trang trọng hơn; mua quid đầy đủ; đi với 6NF; thực hiện một danh mục; các tiện ích để sản xuất SQL; Lượt xem; xử lý Dữ liệu Thiếu một cách nhất quán; loại bỏ hoàn toàn Nulls. Điều này làm giảm khả năng bị tổn thương của bạn đối với chất lượng của các nhà phát triển của bạn; họ có thể quên đi các vấn đề bí truyền của EAV / 6NF, sử dụng Chế độ xem và tập trung vào logic ứng dụng.