Làm thế nào tôi có thể lập luận thuyết phục chống lại việc sao chép các cột cơ sở dữ liệu?


47

Tôi đã bắt đầu làm việc tại một tổ chức mới và một trong những mẫu tôi đã thấy trong cơ sở dữ liệu là sao chép các trường để giúp các nhà phân tích kinh doanh viết dễ dàng hơn. Chúng tôi đang sử dụng Django và ORM của nó.

Trong một trường hợp, chúng tôi giữ một đối tượng MedicalRecordNumber với một chuỗi duy nhất xác định một bệnh nhân trong một bối cảnh nhất định. Chúng tôi có các đối tượng Đăng ký theo dõi bệnh nhân và có liên quan đến MedicalRecordNumbers , nhưng thay vì sử dụng mối quan hệ khóa ngoài, họ sao chép chuỗi để họ có thể tránh viết liên kết ( không phải vì lý do hiệu suất). Mẫu này là phổ biến trong toàn bộ cơ sở dữ liệu.

Đối với tôi tầm quan trọng của một mô hình dữ liệu sạch sẽ chỉ là để tôi có thể nghĩ về nó tốt. Sự phức tạp không cần thiết là sự lãng phí thời gian xử lý nhận thức hạn chế của tôi. Đó là một vấn đề có hệ thống. Không thoải mái khi viết tham gia là một vấn đề kỹ năng chỉnh lưu. Tôi không nhất thiết muốn ủng hộ việc quay lại và thay đổi lược đồ, nhưng tôi rất muốn có thể nói rõ một cách thuyết phục các vấn đề với kiểu sao chép này.


2
"Không thoải mái khi viết tham gia" nghĩa là gì? Làm thế nào để họ giải thích điều đó?
scriptin

9
Những người này làm việc cho bạn? Bạn có phải là người giám sát của họ? Hầu hết các biện minh của bạn có thể được tìm thấy ở đây: en.wikipedia.org/wiki/Database_n normalization . Vâng, họ cần phải trở nên tốt hơn trong việc sử dụng tham gia.
Robert Harvey

1
Bạn đã tìm kiếm các tài liệu về lý do tại sao bình thường hóa là mong muốn?
Nathan Tuggy

17
Sẽ không thêm các chế độ xem tham gia nội bộ để thực hiện các truy vấn bằng văn bản dễ dàng như vậy? Bạn có thể đề nghị họ như là một thay thế.
CodeInChaos

1
Bạn đã giao tiếp điều này (một cách lịch sự) với các đồng nghiệp và người cao niên của bạn? Biện minh của họ là gì, họ đang cân nhắc điều gì? Có nhiều lý do có thể tại sao điều này có thể là một ý tưởng tốt (mặc dù bạn nói "hiệu suất không phải là lý do", bằng chứng nào bạn có để hỗ trợ điều đó?). Trước khi buộc tội họ quá lười biếng và / hoặc cứng nhắc, bạn đã xem xét (và hỏi) lý do họ có để thiết kế theo cách đó chưa? Có lẽ có nhiều đọc hơn viết (phân tích DB nặng)? Thay đổi theo dõi? Dữ liệu lịch sử? Hỏi mọi người - ai đó có thể biết lý do thực sự .
Luaan

Câu trả lời:


128

Cơ sở dữ liệu hoạt động của bạn nên được chuẩn hóa cao, để giảm sự bất thường .

Cơ sở dữ liệu phân tích (kho) của bạn nên được chuẩn hóa cao, để dễ dàng phân tích.

Nếu bạn không có cơ sở dữ liệu phân tích riêng biệt, bạn nên thực hiện một số quan điểm [phi vật chất hóa] rất không chuẩn hóa.

Nếu bạn nói với các nhà phân tích / quản lý kinh doanh cấp cao của bạn thực hiện nhiều liên kết để phân tích đơn giản, tốt, bạn có thể bị sa thải.

Thiết kế kho dữ liệu Agile là một cuốn sách tốt

Xem mẹo nhanh về kho dữ liệu bẩn của tôi ở đây


9
Đây là cách đúng đắn để đi.
Nit

6
+1 Đây chính xác là mục đích của Chế độ xem: cho phép chế độ xem không chuẩn hóa trên cơ sở dữ liệu được chuẩn hóa.
Nzall

4
Hoàn toàn chính xác, nhưng tôi nghĩ "giảm bất thường" nên được nhấn mạnh hơn, vì đó là câu trả lời chính cho câu hỏi. Phổ biến nhất (chỉ?) Bất thường bạn sẽ thấy có sự trùng lặp dữ liệu / denormalization là các cột sẽ bằng cách nào đó được dân cư với dữ liệu trái ngược nhau cùng một lúc, để lại cho bạn không có cách nào để biết những gì các dữ liệu thực tế được cho là được và không cách xác định những gì đã đi sai. Cái sau có thể được giảm thiểu bằng cách theo dõi các thay đổi lớn, nhưng điều này sẽ không rẻ hoặc nhanh chóng vượt qua và tìm ra vấn đề. Chi phí hiệu quả hơn để tránh vấn đề hoàn toàn.
jpmc26

2
Một góc độ khác cần xem xét là, ngay cả khi giả sử các nhà phát triển có khả năng giữ dữ liệu chính xác (nghi ngờ), nó sẽ trở thành một sự tiêu hao lớn đối với tài nguyên của họ để đảm bảo rằng mọi trường trùng lặp đều được cập nhật khi cần duy trì tính nhất quán.
Nate CK

1
@Panzercrisis Cách duy nhất để giao dịch là "ẩn" là nếu bạn có một cam kết tự động chạy ở cuối truy vấn của bạn. Điều này thường không phải là trường hợp cho một cơ sở dữ liệu sản xuất. Trong một ứng dụng, các giao dịch nên được bắt đầu tự động và một cam kết sẽ được ban hành riêng biệt với truy vấn. Đây là một khoản đầu tư nhỏ trong ứng dụng, nhưng nó đơn giản hóa các thay đổi mã liên quan đến việc thêm các cuộc gọi cơ sở dữ liệu và giảm mức độ suy nghĩ của nhà phát triển (cải thiện tốc độ dev, giảm lỗi dev). Kiểu thiết kế đó cũng phù hợp với những thứ như kết nối tổng hợp.
jpmc26

57

Tôi hiểu, tại sao ai đó muốn tránh viết một tham gia cho mỗi lựa chọn.

Nhưng bạn có thể tạo một lần một lượt xem với phép nối và sử dụng nó thay vì bảng không chuẩn hóa của bạn.

Vì vậy, bạn kết hợp lợi thế của chuẩn hóa với sự thuận tiện của một lựa chọn dễ dàng.


12
Lượt xem là bạn của bạn. Sử dụng chúng một cách tự do. Và để thực hiện, bạn thậm chí có thể sử dụng các khung nhìn được Vật chất hóa nếu RDBMS của bạn hỗ trợ chúng.
VH-NZZ

13

Các câu trả lời đã được nêu lên khá nhiều bao gồm "cách tránh trùng lặp" (sử dụng lượt xem) nhưng không phải tại sao. Về cơ bản, chúng cho thấy rằng sao chép các cột là giải pháp sai cho vấn đề làm cho việc viết truy vấn dễ dàng hơn. Nhưng câu hỏi "tại sao không sao chép bất kỳ cột ngẫu nhiên nào chỉ vì cái quái gì đó?" vẫn đứng vững.

Câu trả lời là "Vì luật của Murphy". Luật pháp của Murphy quy định rằng:

Nếu một cái gì đó có thể đi sai, nó sẽ.

Trong trường hợp này, nội dung của từng trường hàng của một cột trùng lặp được cho là giống hệt với nội dung của từng trường hàng tương ứng của cột ban đầu. Điều có thể sai, là nội dung của một số trường hàng có thể khác với bản gốc, tàn phá. Bạn có thể nghĩ rằng bạn đã thực hiện tất cả các biện pháp phòng ngừa có thể hiểu được để đảm bảo rằng chúng sẽ không khác nhau, nhưng luật của Murphy nói rằng vì chúng có thể khác nhau, chúng sẽ khác nhau. Và tàn phá sẽ xảy ra sau đó.

Như một ví dụ về cách điều này có thể xảy ra, chỉ cần xem xét thực tế rằng các cột trùng lặp không được lấp đầy bằng phép thuật; ai đó phải thực sự viết mã lưu trữ giá trị trong đó bất cứ khi nào các hàng được tạo trong bảng gốc và ai đó phải viết mã để cập nhật chúng bất cứ khi nào bản gốc được sửa đổi. Đặt sang một bên thực tế rằng điều này đang tạo thêm gánh nặng quá mức cho mã nhập dữ liệu vào cơ sở dữ liệu, (theo định nghĩa, quan trọng hơn nhiều so với bất kỳ mã nào chỉ đơn giản là truy vấn cơ sở dữ liệu,) ai đó, ở một số trường hợp nhất định có thể quên để thực hiện sao chép này. Sau đó, các giá trị sẽ khác nhau. Hoặc họ có thể nhớ thực hiện sao chép, nhưng không phải trong một giao dịch, do đó, trong một số điều kiện lỗi hiếm gặp, có thể bị bỏ qua. Nhưng tôi không thực sự cần phải lãng phí thời gian để viết những ví dụ này,Nếu nó có thể đi sai, nó sẽ.


12

Nghĩ về nó dưới dạng đánh đổi hơn là tốt / xấu sẽ hiệu quả hơn. Họ đang kinh doanh các lợi thế của chuẩn hóa (đặc biệt là tính nhất quán) để có lợi thế về khả năng sử dụng truy vấn.

Ở một thái cực, cơ sở dữ liệu sẽ trở nên vô dụng nếu dữ liệu không nhất quán nghiêm trọng. Ở một thái cực khác, cơ sở dữ liệu sẽ trở nên vô dụng nếu quá khó khăn cho những người cần truy vấn nó mỗi ngày để có kết quả mà họ có thể tin cậy.

Bạn có thể làm gì để giảm thiểu rủi ro và chi phí?

  • Xây dựng một công cụ kiểm tra tính nhất quán và chạy nó thường xuyên.
  • Định tuyến truy cập ghi thông qua phần mềm cập nhật dữ liệu sao chép một cách nhất quán.
  • Thêm chế độ xem hoặc xây dựng các công cụ truy vấn tự động tham gia để người kinh doanh có thể suy nghĩ về thông tin thay vì nội bộ DB.

6

Tôi nghĩ lập luận mạnh mẽ nhất về bình thường hóa dữ liệu cho các nhà phân tích kinh doanh là nó thúc đẩy tính toàn vẹn dữ liệu. Nếu dữ liệu chính của bạn được lưu trữ ở một nơi duy nhất (một cột, trong một bảng), thì rất ít khả năng dữ liệu sẽ bị hỏng do cập nhật không chính xác. Tôi nghĩ rằng họ có thể quan tâm đến tầm quan trọng của tính toàn vẹn dữ liệu, vì vậy đây có thể là một cách tốt để thuyết phục họ cập nhật cách tương tác với cơ sở dữ liệu.

Một phương pháp truy vấn khó hơn một chút có khả năng sẽ thích hợp hơn với tham nhũng dữ liệu tiềm năng.


6
Người của anh ta sẽ lập luận rằng họ đủ tốt để đảm bảo rằng tất cả dữ liệu đang được cập nhật đúng cách (tiền đề tôi tranh chấp, nếu họ không thoải mái với việc tham gia). Có lẽ một lý lẽ tốt hơn là bạn mất hầu hết các lợi ích của ACID mà RDBMS cung cấp, nếu bạn tránh sự bình thường hóa.
Robert Harvey

4
Có thể, nhưng tất cả chỉ là một câu hỏi về rủi ro. Họ có sẵn sàng chấp nhận rủi ro làm hỏng cơ sở dữ liệu vì nó giúp truy vấn dễ dàng hơn không?
Oleksi

1
Chơi trò bênh vực của quỷ ở đây, một phản biện rõ ràng là, nếu ai đó sẽ làm hỏng một bản cập nhật và dữ liệu bị hỏng, thì đó là một vấn đề có hoặc không bình thường hóa - và, ít nhất, có một số dư thừa trong cơ sở dữ liệu rằng ai đó sẽ nhận thấy sự tham nhũng, và thậm chí có thể sửa chữa nó sau này. (Tất nhiên, việc không chuẩn hóa ad hoc hầu như không phải là sơ đồ phát hiện lỗi đáng tin cậy nhất, nhưng nguyên tắc kiểm tra lỗi thông qua dự phòng là âm thanh: đó là cách hoạt động của sổ sách kế toán kép .)
Ilmari Karonen

Hoặc, để đặt nó theo các thuật ngữ khác, có nhiều hơn về tính toàn vẹn dữ liệu hơn là tính toàn vẹn quan hệ. Với cơ sở dữ liệu được chuẩn hóa hoàn toàn, bạn vẫn có thể duy trì tính toàn vẹn quan hệ hoàn hảo ngay cả khi ai đó làm hỏng bản cập nhật, nhưng điều đó không làm cho dữ liệu được cập nhật không chính xác trở nên ít rác hơn.
Ilmari Karonen

0

Để thêm vào những gì những người khác đã đề nghị ở trên. Đây là một vấn đề quản trị dữ liệu. Bạn cần làm việc với các bên liên quan: kiến ​​trúc sư dữ liệu và người quản lý dữ liệu để phát triển các nguyên tắc dữ liệu, chính sách và quy ước đặt tên.

Hãy kiên nhẫn và làm việc có phương pháp. Thay đổi sẽ không xảy ra qua đêm.


0

Thoát

Thành thật mà nói, bạn có thể dành nhiều tháng để tranh luận về sự bình thường hóa, tính nhất quán và chiến đấu với những con bọ điên gây ra bởi sự lười biếng tuyệt đối, và sau đó bỏ cuộc.

Hoặc bạn chỉ có thể tiết kiệm thời gian, và thất vọng và bỏ ngay bây giờ.

Lập trình viên giỏi là những người rất lười biếng. Họ hiểu nhu cầu của khách hàng và quản lý. Nhưng quan trọng nhất là họ hiểu rằng giải quyết vấn đề tốt, sử dụng các giải pháp được thiết kế tốt và triển khai tốt sẽ tiết kiệm cho cá nhân họ NHIỀU công việc, nỗ lực và quan trọng nhất là đau đớn và căng thẳng.

Vì vậy, bạn sẽ làm việc tốt hơn ở một nơi hiểu và coi trọng kỹ thuật tốt.

Chúc may mắn.


Suy nghĩ lại: Có lẽ thứ họ cần là các công cụ BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_ Processing

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.