2011-12-30 29 views
5

Khi lưu trữ tôn giáo của người dùng trong "Bảng Người dùng", để nếu bạn nhìn xuống một cột bạn sẽ thấy "Cơ đốc nhân" nhiều lần, "Hồi giáo" nhiều lần, v.v ... coi là thất bại của một hình thức bình thường? Biểu mẫu nào?Đây có phải là hình thức thất bại bình thường không?

Con đường tôi nhìn thấy nó:

  • 1nF: Không có cột lặp lại.

  • 2nf: Không có khóa chính được nối, do đó, điều này không áp dụng.

  • 3nf: Không phụ thuộc vào thuộc tính nonkey.

Lưu tôn giáo sử dụng cách này dường như không thất bại bất kỳ hình thức bình thường, tuy nhiên nó dường như rất không hiệu quả. Bình luận?

Trả lời

6

Thiết kế của bạn hỗ trợ tất cả các biểu mẫu bình thường. Nó là tốt mà thuộc tính của bạn có một giá trị chuỗi. Kích thước của kiểu dữ liệu không liên quan đến việc chuẩn hóa.

Mục tiêu bình thường hóa không phải là hiệu quả lưu trữ vật lý - mục tiêu là để ngăn chặn sự bất thường. Và để hỗ trợ hiệu suất hợp lý, tức là lưu trữ một thực tế nhất định chỉ một lần. Trong trường hợp này, thực tế là người dùng trên một hàng nhất định là Christian.

+0

Tôi ước gì tôi đã nghĩ như vậy. – Taymon

+0

Làm thế nào là bất thường sửa đổi dữ liệu thực sự ngăn chặn mà không có một số hạn chế (KIỂM TRA hoặc NGOẠI HỐI) trong mô hình này? (Bỏ qua bất kỳ thực thi mã khách hàng nào thông qua ORM hoặc như vậy) – gbn

+0

Đó là một điểm tuyệt vời mà bạn mang đến. Một KIỂM TRA có thể được đưa vào nhưng sẽ không có nguồn sửa đổi dữ liệu. Bạn có thể hỏi cùng một câu hỏi liên quan đến bất kỳ giá trị dữ liệu nguyên tử nào. Tôi không tin rằng ngăn ngừa dị thường sửa đổi dữ liệu luôn luôn là cần thiết. Cảm thấy tự do để không đồng ý. – user

4

Nguyên nhân bất lợi khi lưu trữ cột theo cách đó là trong không gian lưu trữ khi số hàng tăng lên. Thay vì một cột ký tự, bạn có thể sử dụng ENUM() nếu bạn có một bộ lựa chọn cố định hiếm khi, nếu có, thay đổi, và vẫn tránh tạo thêm một bảng tùy chọn tôn giáo mà tùy chọn này có khóa ngoại . Tuy nhiên, nếu các lựa chọn sẽ là chất lỏng, các quy tắc chuẩn hóa sẽ thích rằng các lựa chọn được đặt vào bảng riêng của chúng với một khóa ngoại trong bảng người dùng của bạn.

Có những ưu điểm khác ngoài dung lượng lưu trữ để giữ chúng trong bảng khác. Sửa đổi chúng là một snap. Để thay đổi Christian để Christianity, bạn có thể làm cho một sự thay đổi duy nhất trong bảng tôn giáo, chứ không phải là làm những tiềm năng đắt tiền (nếu bạn có rất nhiều hàng và tôn giáo không được lập chỉ mục)

UPDATE users SET religion='Christianity' WHERE religion='Christian' 

... bạn có thể làm đơn giản hơn và rẻ hơn

UPDATE religions SET name='Christianity' WHERE id=123 

Tất nhiên, bạn cũng thực thi toàn vẹn dữ liệu bằng cách khóa bàn chống lại tôn giáo. Không thể chèn giá trị không hợp lệ như sai chính tả Christain.

+1

Thông tin chi tiết tuyệt vời, nhưng câu hỏi là viết tắt. Bạn nói "cách không chuẩn hóa". Dạng lỗi thông thường nào được áp dụng ở đây? 1nf, 2nf hoặc 3nf? – user

+1

@ user1122200 Tôi nghĩ rằng nó không phải là một sự vi phạm nghiêm trọng của bất kỳ 3 NF đầu tiên, nhưng sẽ quy mô không hiệu quả. –

+0

Đó là những gì tôi đang yêu cầu. Nó không có vẻ là một hình thức thất bại bình thường cả. Tôi không quan tâm đến việc mở rộng quy mô, chỉ là về hình thức bình thường. Có vẻ như xấu xí và không hiệu quả để lưu trữ nó như thế, nhưng nó sẽ được chuẩn hóa một cách chính xác. – user

1

Tôi giả định rằng có một danh sách các tôn giáo hợp lệ; nếu bạn vừa có người dùng nhập chuỗi của riêng họ, thì bạn phải lưu trữ nó trong bảng người dùng và đây là tất cả các tranh luận.

Giả sử rằng các tôn giáo được lưu trữ trong bảng của riêng chúng. Nếu bạn đang theo dõi các thực hành được thiết lập tốt, bảng này sẽ có khóa chính là số nguyên và tất cả các tham chiếu đến các mục trong bảng trong các bảng khác (chẳng hạn như bảng người dùng) sẽ là khóa ngoài. Phương pháp lưu trữ tôn giáo không vi phạm bất kỳ hình thức bình thường nào (vì tên của một tôn giáo là chìa khóa ứng cử viên cho bảng tôn giáo), nhưng nó vi phạm việc thực hành không sử dụng các chuỗi làm khóa.

(Đây là một sự khác biệt thú vị giữa lý thuyết và thực hành của đại số quan hệ.Trong lý thuyết, một chuỗi không khác với số nguyên, cả hai đều là giá trị toán học nguyên tử. Trong thực tế, các chuỗi có rất nhiều chi phí dẫn đầu các lập trình viên không sử dụng chúng làm khóa.)

Tất nhiên, có những cách khác (chẳng hạn như ENUM đối với một số RDBMS) lưu trữ danh sách các giá trị có thể, mỗi giá trị có những ưu điểm và nhược điểm riêng.

+0

"nhưng nó vi phạm thực hành không sử dụng chuỗi như các phím" Chuỗi sẽ không phải là chìa khóa. Nếu chúng được chuyển đến một bảng riêng biệt, tôi sẽ tạo một ReligionID có số – user

+0

Điểm chính ở đây là hiệu quả. Việc thêm một bảng phụ sẽ có nghĩa là một phép nối thêm, điều này là tốt, nhưng không phải khi chiến lược này được sử dụng cho nhiều thuộc tính. Điều đó có thể dẫn đến nhiều lần tham gia chỉ để kéo thông tin về người dùng. Quá nhiều lần tham gia. Và nếu phương pháp này không vi phạm một hình thức bình thường, tôi thấy không có lý do gì để thêm một bảng phụ. – user

0

Biểu mẫu bình thường của bạn hơi khó chịu. Dạng thông thường thứ hai là phần còn lại của hàng phụ thuộc vào "toàn bộ khóa". Hình thức bình thường thứ ba là phần còn lại của hàng phụ thuộc vào "không có gì ngoài chìa khóa". (Vì vậy, hãy giúp tôi Codd).

Không, trường hợp của bạn như được mô tả không vi phạm bất kỳ hình thức bình thường nào trong ba dạng đầu tiên. (Nó có thể vi phạm thứ sáu, tùy thuộc vào các yếu tố khác).

+0

Các hình thức bình thường như đã nêu là tốt. Phiên bản của bạn sẽ được thiết lập lại. "Toàn bộ khóa" đề cập đến cả hai phần của khóa chính được nối. "Không có gì ngoài khóa" dùng để chỉ một thuộc tính nonkey tùy thuộc vào thuộc tính nonkey khác. – user

+0

Ah, xin lỗi, tôi nghĩ bạn có nghĩa là các khóa chính hỗn hợp ngoài vòng loại bình thường thứ hai. Lỗi của tôi. Tôi đã không nghe thấy 'khóa chính nối' như một cụm từ, vì vậy chỉ cần đoán theo ý nghĩa của nó. –

0

Có một vài nhược điểm với cách tiếp cận này (so với sử dụng khóa ngoại) mà bạn sẽ cần đảm bảo rằng bạn đồng ý. 1 - lãng phí dung lượng lưu trữ. 2 - chậm hơn để truy vấn theo tôn giáo 3 - ai đó có thể đặt dữ liệu vào đó không khớp, ví dụ: chèn "Jedi" theo cách thủ công hoặc thứ gì đó mà bạn có thể không cân nhắc chính xác 4 - không có cách nào để có danh sách các tôn giáo có thể (ví dụ, nếu không có một tôn giáo nào đó trong bảng của bạn, ví dụ, Zoroastrian) nhưng bạn vẫn muốn nó là một khả năng hợp lệ 5 - viết hoa không chính xác có thể gây ra sự cố 6 - khoảng trắng xung quanh chuỗi có thể gây ra sự cố

Chuyên gia chính với kỹ thuật này là dữ liệu nhanh hơn để rút ra (không tham gia trên bàn) và nó cũng nhanh hơn cho một người đọc.

+0

Tôi đã suy nghĩ để sử dụng một enum enum như đề xuất ở đây, hoặc ràng buộc CHECK trong SQL. Điều đó sẽ loại bỏ các lỗi dữ liệu (viết hoa, đánh vần, v.v.). Làm thế nào để bạn nghĩ rằng phương pháp này lãng phí lưu trữ và chậm hơn? – user

Các vấn đề liên quan