Các mục và các mục chuyên biệt: Nhiều bảng có các cột trùng lặp, bảng chính và bảng chi tiết, hoặc ...?

Question

Tôi cần lưu trữ dữ liệu liên quan đến "mục", nơi sẽ có nhiều loại mục khác nhau, tất cả đều có thuộc tính phổ biến và sau đó mỗi loại có thuộc tính bổ sung của riêng nó. Tôi hy vọng đây là một yêu cầu chung; giải pháp thực hành tốt nhất là gì? Chúng tôi đang sử dụng SQL Server.

Hãy sử dụng làm-up dụ:

xe có

• Giá
• Hãy
• Mẫu
• Chủ

(Trong dữ liệu thực tế của chúng tôi , sẽ có 10-15 cột chung)

xe là một xe cộng:.

• Style (sedan, thể thao, vv)
• Màu
• EngineSize

Thuyền là Phương tiện cộng thêm:

• Displacement
• PortOfOrigin

... vv. đối với một số loại sự vật. Trong dữ liệu thực của chúng tôi, mỗi loại chuyên biệt thường sẽ thêm 2-5 cột; sẽ có 5 loại để bắt đầu. Chúng tôi sẽ thêm các loại theo thời gian, nhưng có lẽ chỉ có tổng cộng 3 hoặc 4 tổng số (nếu có). Thêm loại yêu cầu phát triển, do đó, nó không giống như "thẻ" có thể được thêm vào bởi người dùng cuối. Chúng tôi giả định việc thêm một loại sẽ yêu cầu thay đổi đối với các tầng DB và tầng khách hàng, và có thể là tầng giữa. Điều đó hoàn toàn ổn.

Chúng tôi sẽ thực hiện nhiều truy vấn trên tất cả các mục (xe, trong ví dụ ở trên); chúng tôi chỉ lo lắng về các chi tiết của một loại mặt hàng cụ thể (Ô tô, Thuyền) hiếm khi.

tôi thấy bốn cách để lưu trữ dữ liệu này:

1. bảng riêng biệt cho Xe hơi, Thuyền, vv với các cột trùng lặp.
2. Một bảng có dữ liệu Vehicle, một bảng cho dữ liệu Car bổ sung và bảng cho dữ liệu bổ sung Boat.
3. Một bảng mục, một bảng thuộc tính mục riêng biệt với một hàng cho mỗi thuộc tính bổ sung. Ví dụ: một lược đồ mềm cho các chi tiết.
4. Một bảng có các cột chung được cung cấp chỉ có ý nghĩa bởi mã không phải DB.

Nhìn vào mỗi:

1. bảng riêng biệt cho Xe hơi, Thuyền, vv với các cột trùng lặp. Ví dụ, khoảng:

   CREATE TABLE [Cars] (
       [Id] IDENTITY PRIMARY KEY, 
       [Price] DECIMAL (19, 4), 
       [Make] NVARCHAR(200), 
       [Model] NVARCHAR(200), 
       [Owner] INT, 
       [Id] INT PRIMARY KEY, 
       [Style] NVARCHAR(200), 
       [Color] NVARCHAR(200), 
       [EngineSize] DECIMAL(19, 2) 
   ) 
   CREATE TABLE [Boats] (
       [Id] IDENTITY PRIMARY KEY, 
       [Price] DECIMAL (19, 4), 
       [Make] NVARCHAR(200), 
       [Model] NVARCHAR(200), 
       [Owner] INT, 
       [Id] INT PRIMARY KEY, 
       [Displacement] DECIMAL(19, 4), 
       [PortOfOrigin] NVARCHAR(200) 
   ) 
   

   đủ đơn giản, Ô tô đi vào Cars và Thuyền đi trong Boats. Nếu chúng ta thêm nhiều loại xe, chúng ta thêm một cái bàn. Nếu chúng ta thêm một cột chung khác, chúng ta phải quay trở lại và thêm nó vào tất cả các bảng xe. Báo cáo chống lại xe nói chung có thể được thực hiện đối với một cái nhìn công đoàn của tất cả các bảng (cẩn thận về cột Id).

2. Một bảng có dữ liệu Vehicle, bảng cho dữ liệu Car bổ sung và bảng cho dữ liệu bổ sung Boat. Ví dụ, khoảng:

   CREATE TABLE [Vehicles] (
       [Id] IDENTITY PRIMARY KEY, 
       [Price] DECIMAL (19, 4), 
       [Make] NVARCHAR(200), 
       [Model] NVARCHAR(200), 
       [Owner] INT, 
       [Type] INT  -- A type ID, e.g. "Car" vs. "Boat" 
   ) 
   CREATE TABLE [Cars] (
       [Id] INT PRIMARY KEY, 
       [Style] NVARCHAR(200), 
       [Color] NVARCHAR(200), 
       [EngineSize] DECIMAL(19, 2) 
   ) 
   CREATE TABLE [Boats] (
       [Id] INT PRIMARY KEY, 
       [Displacement] DECIMAL(19, 4), 
       [PortOfOrigin] NVARCHAR(200) 
   ) 
   

   Vì vậy, mỗi xe sẽ có một hàng trong Vehicles và một hàng liên kết trong Cars. Mỗi Thuyền sẽ có một hàng trong số Vehicles và một hàng được liên kết trong Boats. Nếu chúng ta thêm nhiều loại xe, chúng ta thêm một cái bàn. Báo cáo đối với xe nói chung có thể được thực hiện chỉ với bảng Vehicle. Khi truy xuất chi tiết về một số cụ thể Car hoặc Boat, chúng tôi sử dụng kết nối.

3. Một bảng mục, một bảng thuộc tính mục riêng biệt với một hàng cho mỗi thuộc tính bổ sung. Ví dụ: một lược đồ mềm cho các chi tiết. Ví dụ, khoảng:

   CREATE TABLE [Vehicles] (
       [Id] IDENTITY PRIMARY KEY, 
       [Price] DECIMAL (19, 4), 
       [Make] NVARCHAR(200), 
       [Model] NVARCHAR(200), 
       [Owner] INT, 
       [Type] INT 
   ) 
   CREATE TABLE [VehicleDetails] (
       [VehicleId] INT, 
       [Name] NVARCHAR(200), 
       [Value] NVARCHAR(MAX) 
   ) 
   

   Vì vậy, mỗi xe được một hàng trong Vehicles và ba hàng trong VehicleDetails (một cho mỗi "Style", "Color", và "EngineSize"). Báo cáo được thực hiện phần lớn trên bảng Vehicle. Báo cáo về chi tiết bắt đầu nhận được nhanh chóng lộn xộn. Các lược đồ mềm có vị trí của chúng, chủ yếu là xung quanh dữ liệu do người dùng định nghĩa, nhưng tôi cho rằng đây không phải là lựa chọn tốt ở đây.

4. Một bảng với các cột chung cho ý nghĩa chỉ cho phép code-DB phi:

   CREATE TABLE [Vehicles] (
       [Id] IDENTITY PRIMARY KEY, 
       [Price] DECIMAL (19, 4), 
       [Make] NVARCHAR(200), 
       [Model] NVARCHAR(200), 
       [Owner] INT, 
       [Type] INT, 
       [Detail01] NVARCHAR(MAX), 
       [Detail02] NVARCHAR(MAX), 
       [Detail03] NVARCHAR(MAX), 
       [Detail04] NVARCHAR(MAX), 
       [Detail05] NVARCHAR(MAX), 
       [Detail06] NVARCHAR(MAX), 
       [Detail07] NVARCHAR(MAX), 
       [Detail08] NVARCHAR(MAX), 
       [Detail09] NVARCHAR(MAX), 
       [Detail10] NVARCHAR(MAX) 
   ) 
   

   dữ liệu Vì vậy, xe sẽ gán Style Detail01, màu để Detail02 và EngineSize để Detail03; cho Thuyền, chúng tôi sẽ đặt Displacement vào Detail01 và PortOfOrigin trong Detail02. Tương tự, có thể có một vị trí cho điều này với các lược đồ được xác định bởi người dùng cuối, nhưng tôi đoán đây không phải là câu trả lời hay khi bạn có thể kiểm soát cấu trúc DB.

Answer 1

Tùy theo.

Phương pháp tiếp cận 1 là tốt nhất cho các tình huống mà hầu hết các thuộc tính sẽ phổ biến đối với hầu hết các loại.

Phương pháp 2 là tốt nhất cho các tình huống mà ít thuộc tính sẽ phổ biến đối với hầu hết các loại.

Phương pháp tiếp cận 3 về cơ bản là tiếp cận 1, với phương pháp thuộc tính-Giá trị thuộc tính để xử lý các thuộc tính loại cụ thể.Cách tiếp cận này là tốt nhất cho các tình huống mà hầu hết các thuộc tính sẽ phổ biến đối với hầu hết các loại và rất khó dự đoán các thuộc tính bổ sung nào sẽ được yêu cầu - điều này khá phổ biến trong các trường hợp yêu cầu các trường do người dùng tạo.

Tiếp cận 4 không phải là một ý tưởng tốt trong mọi tình huống - nó loại bỏ nội dung ngữ nghĩa từ lớp siêu dữ liệu vào các lớp mã, trong khi giữ lại cứng nhắc của cách tiếp cận 1.

Ngoài ra còn có một cách tiếp cận có thể - một tinh khiết Entity-Attribute-Value phương pháp tiếp cận (về cơ bản là một sự pha trộn của phương pháp tiếp cận 3 và 4). Điều này thường được coi là một mô hình chống, do sự phức tạp và hiệu năng kém được tạo ra khi được triển khai trên một RDBMS. Tuy nhiên, có một số tình huống mà nó là cách tiếp cận duy nhất có thể - chủ yếu, nơi mà các mối quan hệ thực thể không được biết trước.