Việc lưu trữ một danh sách các chuỗi trong trường cơ sở dữ liệu duy nhất là một ý tưởng tồi? Tại sao?

Gần đây, tôi bắt đầu làm việc trên một số hệ thống di sản. Những người đã phát triển nó, đã nảy ra một ý tưởng để lưu trữ danh sách các chuỗi trong một trường duy nhất của bảng cơ sở dữ liệu. Hãy nói rằng nó là một định danh cho đối tượng không có bất kỳ biểu diễn cũng như dữ liệu trong cơ sở dữ liệu. Phạm vi của các định danh đó sẽ tương đối nhỏ trong sản xuất.

Mặt khác, trực giác và "sở thích thiết kế tốt" của tôi nói với tôi rằng nó nên được trình bày trong bảng riêng biệt (tương tự như bảng được sử dụng để thể hiện quan hệ nhiều-nhiều).

Là cách tiếp cận của họ thực sự xấu và sẽ tốt hơn để bắt đầu tái cấu trúc? Nếu có, hậu quả xấu nào mà thiết kế ban đầu có thể gây ra trong tương lai? Có bất kỳ nguyên tắc thiết kế quan hệ nào giải thích cách tiếp cận đó?

Chỉnh sửa để trả lời cho ý kiến:

Như tôi cho rằng, họ đã không sử dụng phương pháp này để giải quyết một số vấn đề cụ thể như cấu trúc phân cấp một cách khó khăn. Kịch bản có thể xảy ra nhất là trường hợp họ chỉ đơn giản làm việc dưới áp lực thời gian và cần thực hiện các tính năng mới càng nhanh càng tốt.

Tôi chắc chắn rằng trước đây trường đại diện cho giá trị duy nhất. Họ sẽ triển khai tính năng để lưu trữ nhiều hơn một giá trị và cố gắng tránh di chuyển cơ sở dữ liệu.

Datamodel không được chuẩn hóa; để được như vậy nó sẽ cần một bảng riêng như bạn nói. Về mặt đó, nó không phải là thực hành dữ liệu đặc biệt tốt.

Cho dù nó đã được thực hiện vì một lý do tốt hay không rất khó để xác định. Có thể hình dung, đơn giản hóa hoặc hiệu suất mã hóa có thể là động lực. Có khả năng là trường ban đầu chứa một mã định danh, các yêu cầu đã thay đổi và các nhà phát triển không có thời gian hoặc thiên hướng để tính lại.

Có lẽ quan trọng hơn là bạn có nên tự cấu trúc lại hay không. Trong trường hợp tương tự, tôi sẽ không tái cấu trúc trước một trường hợp như thế này theo mặc định. Tôi sẽ xem xét nó nếu một trong những điều sau đây được áp dụng:

1. bạn có bằng chứng cho thấy điều này gây ra vấn đề, ví dụ như từ nhật ký vấn đề cũ
2. bạn biết một sự thật rằng bạn sẽ thực hiện các thay đổi chức năng trong khu vực đó
3. mã xử lý dữ liệu đặc biệt phức tạp và khó lý do.

Những gì tôi sẽ làm và TBH Tôi muốn giới thiệu điều này bất cứ khi nào bạn tiếp quản một ứng dụng cũ, sẽ bắt đầu một wiki (hoặc tương đương) và các trường hợp tài liệu như thế này. Ví dụ,

• các vấn đề bạn đã tìm thấy như nếp nhăn dữ liệu
• những thay đổi bạn dự định thực hiện
• những thay đổi bạn không có kế hoạch thực hiện nhưng sẽ có nếu có thời gian
• các lĩnh vực mã khó lý do về
• các lĩnh vực mã mà bạn thấy khó duy trì.

Tôi đã thấy rằng đây là một bản ghi nhớ trợ giúp hữu ích cho tôi khi tôi làm việc và / hoặc quay trở lại một cơ sở mã. Nó cũng có thể rất hữu ích cho người kế nhiệm của bạn khi họ cần bắt đầu học codebase.

Việc lưu trữ một danh sách các chuỗi trong trường cơ sở dữ liệu duy nhất là một ý tưởng tồi?

Nó thường được coi là vi phạm bình thường hóa.

Tuy nhiên, đôi khi điều này được sử dụng một giải pháp cho một vấn đề, ví dụ như trong cấu trúc phân cấp, trong đó một chuỗi đường dẫn có độ dài thay đổi của một số loại đại diện cho cấu trúc.

Trong số các vấn đề với danh sách các mục trong một chuỗi có thể là:

• trong truy vấn, điều này có nghĩa là sử dụng tìm kiếm chuỗi thay vì tính toán quan hệ; lập chỉ mục dữ liệu có thể có vấn đề.
• có một câu hỏi về ý nghĩa của thứ tự của các mục trong danh sách và rằng nhiều khả năng bạn không thể thực thi bất cứ điều gì khi đặt hàng như một ràng buộc đối với db.
• có vấn đề về ký tự phân cách và tiềm năng cho vấn đề thoát / không thoát nhân vật với các mục riêng lẻ.
• có tiềm năng cho các mục trùng lặp trong cùng một danh sách; một lần nữa điều này xuất phát từ việc không thể thực thi trực tiếp các ràng buộc (mặc dù có thể một hàm kích hoạt có thể kiểm tra các ràng buộc).
• một mục duy nhất vẫn là một danh sách, nhưng có thể bị nhầm là không vì chúng ta không thể nói (hoặc hỏi) cơ sở dữ liệu rằng loại thực sự là một danh sách. Điều này có thể có vấn đề nếu hầu hết các hàng chỉ có một mục trong danh sách, khi một số có nhiều mục: không có cách nào để thực thi việc sử dụng đúng cột trong danh sách.

Đó là một antipotype phổ biến để làm điều này.

Yêu cầu của bạn thay đổi và bây giờ bạn cần nhiều giá trị hơn ở một nơi mà trước đây bạn chỉ cần một giá trị. Giống như một cuốn sách chỉ có một tác giả phải không? Ai có thể đoán một cuốn sách có nhiều tác giả? Đây là một cách dễ dàng để thực hiện thay đổi yêu cầu này mà không phải thay đổi lược đồ cơ sở dữ liệu của bạn.

Có một số nhược điểm mặc dù.

• Các truy vấn trở nên khó khăn hơn vì bây giờ bạn đã xác định dữ liệu được kết hợp trong 1 trường.
• Bạn không còn có thể sử dụng "=" mà phải sử dụng một cái gì đó như "thích". Mà sẽ giết hiệu suất.
• Bạn mất khả năng tham gia vào lĩnh vực đó.
• Hãy thử đếm / tổng, v.v., nó sẽ không hoạt động.
• Cập nhật, trở nên khó xử.
• Bạn nhận được như giới hạn nhân tạo bởi vì bạn đã chọn một varchar (10) để giữ danh sách tương đương của bạn.
• và hơn thế nữa.

Vì vậy, về cơ bản, xin vui lòng không làm điều này.

Về cơ bản, bạn đang lấy ra "quan hệ" trong "cơ sở dữ liệu quan hệ".

Có rất nhiều tranh luận cho việc chúng tôi là một ý tưởng tồi. Tôi nghĩ sẽ công bằng khi thêm một số lý do tại sao nó sẽ là một ý tưởng tốt, hoặc ít nhất là OK. Không chắc có bao nhiêu trong số này áp dụng trường hợp cụ thể của intis, nhưng có vẻ như ít nhất các nhận xét về hiệu suất đã được thực hiện có liên quan:

• nếu số lượng và độ dài của chuỗi bị giới hạn nghiêm ngặt, thì chênh lệch hiệu suất sẽ không đáng kể. Ít nhất là đối với một số trường hợp cạnh, hiệu suất sẽ tốt hơn, vì bạn không cần tham gia.
• tùy thuộc vào cách sử dụng chính của trường, hình thức này có thể dễ xử lý hơn.
• nếu danh sách được sắp xếp và dữ liệu không yêu cầu khóa ngoại, các trường danh sách vượt trội hơn nhiều so với bất kỳ cơ sở dữ liệu quan hệ nào có thể cung cấp về vấn đề này.
• trở thành con heo đất đơn giản trên lĩnh vực số ít hiện tại có thể là một lựa chọn khôn ngoan trong các hệ thống mà việc di chuyển lược đồ tốn kém. Đây chắc chắn là một khoản nợ kỹ thuật, nhưng nó có thể là loại đáng để lấy và không bao giờ trả lại, ngay cả khi bạn cần phải chảy một số tiền lãi ngay bây giờ và sau đó.

Khi cố gắng tái cấu trúc, trước tiên bạn nên hiểu lý do đằng sau các lựa chọn thiết kế trước đó. Hãy chắc chắn rằng các điều kiện và yêu cầu đã thực sự thay đổi đủ để đảm bảo chi phí và rủi ro.