Lựa chọn thay thế nào tồn tại khi một bảng yêu cầu quá nhiều khóa ngoại?

Chúng tôi có một bảng cơ sở xác định các bộ phận và chứa thông tin như số phần, mô tả, giá cả, trọng lượng, v.v. Chúng tôi cũng có khoảng 400 bảng tham chiếu bảng cơ sở và cung cấp thông tin bổ sung về các phần dựa trên loại / danh mục của chúng.

Chúng tôi đã bắt đầu bằng cách sử dụng các ràng buộc khóa ngoại để có thể xóa một phần khỏi bảng cơ sở nếu nó được tham chiếu trong một trong 400 bảng cụ thể của phần nhưng chúng tôi đã nhanh chóng đạt được tối đa 253 khóa ngoại được đề xuất cho SQL Server 2005.

Có sự thay thế nào cho khóa ngoại trong tình huống này sẽ đảm bảo tính toàn vẹn dữ liệu không? Chúng tôi chưa thấy vấn đề về hiệu suất khi truy cập dữ liệu nhưng việc cập nhật một phần hiện có trong bảng cơ sở sẽ thất bại vì kế hoạch truy vấn quá phức tạp.

sql-server-2005 foreign-key

— jellomonkey
nguồn

Bạn có thực sự nghĩ rằng bạn cần 400 bảng cụ thể không? Làm thế nào khác nhau mỗi bảng này, thực sự? Tôi nghĩ rằng bạn đang cố gắng sửa phần sai của thiết kế này.

— Aaron Bertrand

Có bao nhiêu hàng bạn đang xử lý trong cơ sở dữ liệu này?

— Jon Seigel

Tôi phải đồng ý với Aaron Bertrand, nếu thiết kế của bạn yêu cầu bạn tối đa hóa các khóa ngoại của máy chủ sql hỗ trợ, có lẽ đã đến lúc xem xét thiết kế lại.

— DForck42

Tôi đã thực hiện nhiều thiết kế trong lĩnh vực này - giá cả, quản lý sản phẩm, thông số kỹ thuật sản phẩm. Ngay cả trong các thiết kế được chuẩn hóa cao, tôi chưa bao giờ đến gần nhiều FK trên cùng một bảng. Có lẽ bạn đang thực hiện một số loại chiến lược phân vùng dữ liệu (theo máy khách hoặc thời gian hoặc một cái gì đó tương tự) khiến bạn phải thiết kế theo hướng này? Thật khó để đưa ra câu trả lời nếu không có thêm thông tin về mục tiêu thiết kế và thiết kế của bạn.

— Karen Lopez

Bạn có thể cung cấp ví dụ về lược đồ để nói 5 trong số các bảng này không ...

— Damir Sudarevic 15/03/13

Câu trả lời:

Nếu có bất kỳ cách nào để nhóm các bộ phận, bạn có thể giới thiệu các bảng trung gian như một cách giải quyết. Điều này sẽ không làm việc.

Parts
+ Table 1
+ Table 2
+ ...
+ Table 400

Nhưng một cái gì đó dọc theo những dòng này có thể.

Parts
+ RedOrangeYellow parts
  + Table 1
  + Table 2
  + ...
  + Table 200

+ GreenBlueIndigoViolet parts
  + Table 201
  + Table 202
  + ...
  + Table 400

Tuy nhiên, tôi muốn xem xét kỹ DDL của bạn trước khi tôi khuyên bạn nên làm điều này. Và nếu bạn làm điều này, đừng bắt đầu ném số ID khắp nơi. Bạn phải có thể trực tiếp tham gia "Bảng 400" vào "Bộ phận" mà không bao gồm "Bộ phận GreenBlueInigoViolet".

— Mike Sherrill 'Nhớ lại mèo'
nguồn

Nếu bạn thực sự không thể kết hợp các bảng, tại sao không tạo một TRIGGERbảng trên cơ sở để ngăn chặn xóa?

Bắt đầu tại đây: http://msdn.microsoft.com/en-us/l Library / ms189799 (v = sql.90) .aspx

— Stu
nguồn

-4

Thay thế hơn 400 bảng bằng một bảng. Chỉ cần 3 trường (tự động +1 hoặc bất kỳ khóa chính nào nếu bạn muốn, không cần phải có nó, bạn có thể tạo nó từ các trường khác)

Giá trị thuộc tính ID vật phẩm

Vì vậy, trong các bảng khác của bạn, mỗi trường đại diện cho một thuộc tính, trong bảng này các thuộc tính của bạn đều nằm trong một trường. Bạn sẽ có một cái gì đó như thế này

Giá trị thuộc tính ItemID

Chất liệu len

Sock màu đỏ

Sock Trọng lượng 20 pounds

Hành tinh ngoài hành tinh Alpha Centauri

Màu tím ngoài hành tinh

Người nước ngoài thân thiện

Các ItemID có lẽ phải là một số / chữ số ofc. Sau đó, bạn chỉ cần crosstab w / Atrribution làm tiêu đề cột khi cần thiết để tạo các bảng như bạn muốn. Điều này cũng cho phép truy vấn tốt hơn cho những thứ như "Hiển thị cho tôi tất cả các vật phẩm từ Alpha Centauri" có thể mang lại cho bạn Người ngoài hành tinh và cả mảnh Thiên thạch có chứa bệnh dịch quét sạch loài người (nó sẽ đến .....)

Tối ưu hóa có thể khó khăn tùy thuộc vào có bao nhiêu hồ sơ nhưng đó là cách tốt hơn nhiều để thiết kế này. Tôi đã làm tương tự cho một cơ sở dữ liệu chứa một loạt các công thức nấu ăn (10k +) có vài chồng chéo. Làm việc tốt trong trường hợp đó. Không có bất kỳ vấn đề tốc độ thực sự. Bạn có thể khó hơn tùy thuộc vào số lượng bạn đang đối phó.

— người dùng2125055
nguồn

Đây được gọi là mô hình Giá trị thuộc tính thực thể và thông thường nó là một ý tưởng khá khủng khiếp vì nhiều lý do. Đối với ví dụ của bạn về kịch bản "alpha centauri", bạn sẽ xem xét có thể 2 lần quét bảng và các chỉ mục không thể được sử dụng. Ngoài ra, nó vô hiệu hóa bất kỳ lợi thế nào đối với các loại dữ liệu, làm cho các ràng buộc quan hệ là không thể và thường không thể tối ưu hóa hoặc có thể mở rộng ở bất kỳ mức độ nào. Nếu bạn cần lưu trữ hơn một trăm hàng như thế này, thì không.

— JNK

Như @JNK điểm, nó thường không phải là một giải pháp tốt. Và thậm chí tệ hơn khi bạn làm điều đó chỉ với một bảng. Tôi muốn nói tối thiểu là 3 bảng ( Entity, Entity_Attribute, Entity_Attribute_Value). Nếu bạn muốn thêm điều trị bán đúng cho các kiểu dữ liệu và ràng buộc tham chiếu khác nhau, bạn sẽ cần nhiều hơn nữa.

— ypercubeᵀᴹ

Mặc dù OP có thể sắp đạt đến một số giới hạn với thiết kế chuẩn hóa truyền thống do sự phức tạp tuyệt đối của các thực thể trong hệ thống của họ, hầu hết các hệ thống cực kỳ phức tạp không thực sự xử lý tốt hơn trong EAV, vì nó cung cấp mức độ ứng dụng và mức độ ứng dụng yếu hơn nhiều tính toàn vẹn tham chiếu vì dữ liệu được lưu trữ khá chung chung. EAV có vị trí hữu ích của nó, nhưng tôi sẽ không sẵn sàng giới thiệu nó như một câu trả lời cho vấn đề này như đã nêu.

— Cade Roux

Huh, học một cái gì đó mới mỗi ngày. Tôi tự học và đôi khi tôi đã nghĩ ra cách giải quyết vấn đề công thức tôi gặp phải, điều này nghe có vẻ giống với vấn đề này. À Cảm ơn thông tin về điều đó, tôi sẽ xem xét EAV, có lẽ có một cách sạch hơn để giải quyết vấn đề của tôi. Có thể nó hoạt động dễ dàng hơn đối với tôi vì tất cả các giá trị là cùng một kiểu dữ liệu. Tôi không biết.

— dùng2125055

@ user2125055 Không có vấn đề gì, và đừng nhận bất kỳ lời chỉ trích nào. Chúng tôi chỉ hạ thấp ý tưởng sử dụng EAV! Chắc chắn có những trường hợp sử dụng có ý nghĩa, nhưng vì những nhược điểm bạn cần phải rất cẩn thận với nó.

— JNK