Vâng, đó là một ý tưởng khủng khiếp.
Thay vì đi:
SELECT Deal.Name, DealCategory.Name
FROM Deal
INNER JOIN
DealCategories ON Deal.DealID = DealCategories.DealID
INNER JOIN
DealCategory ON DealCategories.DealCategoryID = DealCategory.DealCategoryID
WHERE Deal.DealID = 1234
Bây giờ bạn phải đi:
SELECT Deal.ID, Deal.Name, DealCategories
FROM Deal
WHERE Deal.DealID = 1234
Sau đó, bạn cần thực hiện các công cụ trong mã ứng dụng của mình để chia danh sách dấu phẩy đó thành các số riêng lẻ, sau đó truy vấn cơ sở dữ liệu một cách riêng biệt:
SELECT DealCategory.Name
FROM DealCategory
WHERE DealCategory.DealCategoryID IN (<<that list from before>>)
Mô hình thiết kế này bắt nguồn từ sự hiểu lầm hoàn toàn về mô hình quan hệ (Bạn không phải sợ các bảng. Bàn là bạn của bạn. Sử dụng chúng), hoặc một niềm tin sai lầm kỳ lạ là nhanh hơn để lấy danh sách được phân tách bằng dấu phẩy và phân tách nó trong mã ứng dụng hơn là thêm một bảng liên kết ( không bao giờ được). Tùy chọn thứ ba là họ không đủ tự tin / đủ năng lực với SQL để có thể thiết lập khóa ngoại, nhưng nếu đó là trường hợp họ không nên làm gì với thiết kế mô hình quan hệ.
SQL Antipotypes (Karwin, 2010) dành toàn bộ một chương cho antipotype này (mà ông gọi là 'Jaywalking'), trang 15-23. Ngoài ra, tác giả đã đăng một câu hỏi tương tự tại SO . Những điểm chính anh ấy lưu ý (như áp dụng cho ví dụ này) là:
- Truy vấn cho tất cả các giao dịch trong một danh mục cụ thể khá phức tạp (cách dễ nhất để giải quyết vấn đề đó là một biểu thức chính quy, nhưng một biểu thức chính quy là một vấn đề trong chính nó).
- Bạn không thể thực thi tính toàn vẹn tham chiếu mà không có mối quan hệ khóa nước ngoài. Nếu bạn xóa DealC Category nr. # 26, sau đó, trong mã ứng dụng của bạn, phải trải qua từng giao dịch tìm kiếm tài liệu tham khảo cho danh mục # 26 và xóa chúng. Đây là một cái gì đó nên được xử lý ở lớp dữ liệu và phải xử lý nó trong ứng dụng của bạn là một điều rất tồi tệ .
- Các truy vấn tổng hợp (
COUNT, SUMv.v.), một lần nữa, thay đổi từ 'phức tạp' đến 'gần như không thể'. Hỏi nhà phát triển của bạn làm thế nào họ có được danh sách tất cả các danh mục với số lượng giao dịch trong danh mục đó. Với một thiết kế phù hợp, đó là bốn dòng SQL.
- Các cập nhật trở nên khó khăn hơn nhiều (tức là bạn có một thỏa thuận trong năm loại, nhưng bạn muốn loại bỏ hai và thêm ba loại khác). Đó là ba dòng SQL với thiết kế phù hợp.
- Cuối cùng, bạn sẽ chạy vào
VARCHARgiới hạn độ dài danh sách. Mặc dù nếu bạn có một danh sách được phân tách bằng dấu phẩy có hơn 4000 ký tự, rất có thể phân tích cú pháp rằng quái vật sẽ chậm như địa ngục.
- Kéo một danh sách ra khỏi cơ sở dữ liệu, tách nó ra và sau đó quay trở lại cơ sở dữ liệu cho một truy vấn khác về bản chất là chậm hơn một truy vấn.
TLDR: Đây là một thiết kế không hoàn hảo về cơ bản, nó sẽ không mở rộng quy mô, nó giới thiệu sự phức tạp bổ sung cho ngay cả các truy vấn đơn giản nhất và ngay lập tức nó làm chậm ứng dụng của bạn.