Thiết kế tốt nhất để tham khảo nhiều bảng từ cột đơn?


18

Lược đồ đề xuất

Trước hết, đây là một ví dụ về lược đồ được đề xuất của tôi để tham khảo trong suốt bài viết của tôi:

Clothes
---------- 
ClothesID (PK) INT NOT NULL
Name VARCHAR(50) NOT NULL
Color VARCHAR(50) NOT NULL
Price DECIMAL(5,2) NOT NULL
BrandID INT NOT NULL
...

Brand_1
--------
ClothesID (FK/PK) int NOT NULL
ViewingUrl VARCHAR(50) NOT NULL
SomeOtherBrand1SpecificAttr VARCHAR(50) NOT NULL

Brand_2
--------
ClothesID (FK/PK) int NOT NULL
PhotoUrl VARCHAR(50) NOT NULL
SomeOtherBrand2SpecificAttr VARCHAR(50) NOT NULL

Brand_X
--------
ClothesID (FK/PK) int NOT NULL
SomeOtherBrandXSpecificAttr VARCHAR(50) NOT NULL

Báo cáo vấn đề

Tôi có một bảng quần áo có các cột như tên, màu sắc, giá cả, brandid và vv để mô tả các thuộc tính cho một mặt hàng cụ thể của quần áo.

Đây là vấn đề của tôi: các nhãn hiệu quần áo khác nhau đòi hỏi thông tin khác nhau. Thực hành tốt nhất để xử lý một vấn đề như thế này là gì?

Lưu ý rằng đối với mục đích của tôi, cần phải tìm thông tin cụ thể về thương hiệu bắt đầu từ TỪ mục nhập quần áo . Điều này là do lần đầu tiên tôi hiển thị thông tin từ mục nhập quần áo cho người dùng, sau đó tôi phải sử dụng thông tin cụ thể về thương hiệu của mình để mua sản phẩm. Tóm lại, phải có mối quan hệ định hướng giữa quần áo (từ) và bảng brand_x .

Đề xuất / giải pháp hiện tại

Để đối phó với điều này, tôi đã nghĩ đến sơ đồ thiết kế sau:

Bảng quần áo sẽ có một cột thương hiệu có thể có các giá trị id nằm trong khoảng từ 1 đến x, trong đó một id cụ thể tương ứng với một bảng dành riêng cho thương hiệu. Ví dụ: giá trị id 1 sẽ tương ứng với bảng brand_1 (có thể có cột url ), id 2 sẽ tương ứng với brand_2 (có thể có cột nhà cung cấp ), v.v.

Do đó, để liên kết một mục quần áo cụ thể với thông tin cụ thể về thương hiệu của nó, tôi tưởng tượng logic ở cấp ứng dụng sẽ trông giống như thế này:

clothesId = <some value>
brand = query("SELECT brand FROM clothes WHERE id = clothesId")

if (brand == 1) {
    // get brand_1 attributes for given clothesId
} else if (brand == 2) {
    // get brand_2 attributes for given clothesId
} ... etc.

Ý kiến ​​và suy nghĩ khác

Tôi đang cố gắng bình thường hóa toàn bộ cơ sở dữ liệu của mình trong BCNF và mặc dù đây là những gì tôi nghĩ ra, mã ứng dụng kết quả khiến tôi cảm thấy rất lo lắng. Không có cách nào để thực thi các mối quan hệ ngoại trừ ở cấp ứng dụng, và do đó thiết kế cảm thấy rất hack và, tôi dự đoán, rất dễ bị lỗi.

Nghiên cứu

Tôi chắc chắn xem qua các mục trước khi thực hiện một bài viết. Đây là một bài viết với một vấn đề gần giống như tôi quản lý để tìm. Dù sao tôi cũng đã đăng bài này vì có vẻ như câu trả lời duy nhất được cung cấp không có giải pháp dựa trên thiết kế hoặc SQL (nghĩa là nó đề cập đến OOP, kế thừa và giao diện).

Tôi cũng là một người mới khi nói đến thiết kế cơ sở dữ liệu, và vì vậy tôi đánh giá cao bất kỳ hiểu biết nào.


Có vẻ như có nhiều phản hồi hữu ích hơn về Stack Overflow:

Tôi đã đề cập đến các giải pháp ở đó và đề nghị những người khác tìm thấy câu hỏi của tôi cũng làm như vậy.

Mặc dù các liên kết được cung cấp ở trên, tôi vẫn đang tìm kiếm câu trả lời ở đây và sẽ đánh giá cao bất kỳ giải pháp nào được cung cấp!

Tôi đang sử dụng PostgreSQL.

Câu trả lời:


7

Cá nhân tôi không muốn sử dụng lược đồ nhiều bảng cho mục đích này.

  • Thật khó để đảm bảo tính toàn vẹn.
  • Thật khó để duy trì.
  • Thật khó để lọc kết quả.

Tôi đã đặt một mẫu dbfiddle .

Lược đồ bảng đề xuất của tôi:

CREATE TABLE #Brands
(
BrandId int NOT NULL PRIMARY KEY,
BrandName nvarchar(100) NOT NULL 
);

CREATE TABLE #Clothes
(
ClothesId int NOT NULL PRIMARY KEY,
ClothesName nvarchar(100) NOT NULL 
);

-- Lookup table for known attributes
--
CREATE TABLE #Attributes
(
AttrId int NOT NULL PRIMARY KEY,
AttrName nvarchar(100) NOT NULL 
);

-- holds common propeties, url, price, etc.
--
CREATE TABLE #BrandsClothes
(
BrandId int NOT NULL REFERENCES #Brands(BrandId),
ClothesId int NOT NULL REFERENCES #Clothes(ClothesId),
VievingUrl nvarchar(300) NOT NULL,
Price money NOT NULL,
PRIMARY KEY CLUSTERED (BrandId, ClothesId),
INDEX IX_BrandsClothes NONCLUSTERED (ClothesId, BrandId)
);

-- holds specific and unlimited attributes 
--
CREATE TABLE #BCAttributes
(
BrandId int NOT NULL REFERENCES #Brands(BrandId),
ClothesId int NOT NULL REFERENCES #Clothes(ClothesId),
AttrId int NOT NULL REFERENCES #Attributes(AttrId),
AttrValue nvarchar(300) NOT NULL,
PRIMARY KEY CLUSTERED (BrandId, ClothesId, AttrId),
INDEX IX_BCAttributes NONCLUSTERED (ClothesId, BrandId, AttrId)
);

Hãy để tôi chèn một số dữ liệu:

INSERT INTO #Brands VALUES 
(1, 'Brand1'), (2, 'Brand2');

INSERT INTO #Clothes VALUES 
(1, 'Pants'), (2, 'T-Shirt');

INSERT INTO #Attributes VALUES
(1, 'Color'), (2, 'Size'), (3, 'Shape'), (4, 'Provider'), (0, 'Custom');

INSERT INTO #BrandsClothes VALUES
(1, 1, 'http://mysite.com?B=1&C=1', 123.99),
(1, 2, 'http://mysite.com?B=1&C=2', 110.99),
(2, 1, 'http://mysite.com?B=2&C=1', 75.99),
(2, 2, 'http://mysite.com?B=2&C=2', 85.99);

INSERT INTO #BCAttributes VALUES
(1, 1, 1, 'Blue, Red, White'),
(1, 1, 2, '32, 33, 34'),
(1, 2, 1, 'Pearl, Black widow'),
(1, 2, 2, 'M, L, XL'),
(2, 1, 4, 'Levis, G-Star, Armani'),
(2, 1, 3, 'Slim fit, Regular fit, Custom fit'),
(2, 2, 4, 'G-Star, Armani'),
(2, 2, 3, 'Slim fit, Regular fit'),
(2, 2, 0, '15% Discount');

Nếu bạn cần tìm nạp các thuộc tính phổ biến:

SELECT     b.BrandName, c.ClothesName, bc.VievingUrl, bc.Price
FROM       #BrandsClothes bc
INNER JOIN #Brands b
ON         b.BrandId = bc.BrandId
INNER JOIN #Clothes c
ON         c.ClothesId = bc.ClothesId
ORDER BY   bc.BrandId, bc.ClothesId;

BrandName   ClothesName   VievingUrl                  Price
---------   -----------   -------------------------   ------
Brand1      Pants         http://mysite.com?B=1&C=1   123.99
Brand1      T-Shirt       http://mysite.com?B=1&C=2   110.99
Brand2      Pants         http://mysite.com?B=2&C=1    75.99
Brand2      T-Shirt       http://mysite.com?B=2&C=2    85.99

Hoặc bạn có thể dễ dàng lấy Quần áo theo Thương hiệu:

Cho tôi tất cả quần áo của Brand2

SELECT     c.ClothesName, b.BrandName, a.AttrName, bca.AttrValue
FROM       #BCAttributes bca
INNER JOIN #BrandsClothes bc
ON         bc.BrandId = bca.BrandId
AND        bc.ClothesId = bca.ClothesId
INNER JOIN #Brands b
ON         b.BrandId = bc.BrandId
INNER JOIN #Clothes c
ON         c.ClothesId = bc.ClothesId
INNER JOIN #Attributes a
ON         a.AttrId = bca.AttrId
WHERE      bca.ClothesId = 2
ORDER BY   bca.ClothesId, bca.BrandId, bca.AttrId;

ClothesName   BrandName   AttrName   AttrValue
-----------   ---------   --------   ---------------------
T-Shirt       Brand1      Color      Pearl, Black widow
T-Shirt       Brand1      Size       M, L, XL
T-Shirt       Brand2      Custom     15% Discount
T-Shirt       Brand2      Shape      Slim fit, Regular fit
T-Shirt       Brand2      Provider   G-Star, Armani

Nhưng đối với tôi, một trong những điều tốt nhất của lược đồ này là bạn có thể lọc theo Attibutes:

Đưa cho tôi tất cả Quần áo có thuộc tính: Kích thước

SELECT     c.ClothesName, b.BrandName, a.AttrName, bca.AttrValue
FROM       #BCAttributes bca
INNER JOIN #BrandsClothes bc
ON         bc.BrandId = bca.BrandId
AND        bc.ClothesId = bca.ClothesId
INNER JOIN #Brands b
ON         b.BrandId = bc.BrandId
INNER JOIN #Clothes c
ON         c.ClothesId = bc.ClothesId
INNER JOIN #Attributes a
ON         a.AttrId = bca.AttrId
WHERE      bca.AttrId = 2
ORDER BY   bca.ClothesId, bca.BrandId, bca.AttrId;

ClothesName   BrandName   AttrName   AttrValue
-----------   ---------   --------   ----------
Pants         Brand1      Size       32, 33, 34
T-Shirt       Brand1      Size       M, L, XL

Sử dụng lược đồ nhiều bảng bất kỳ truy vấn nào trước đó sẽ yêu cầu xử lý số lượng bảng không giới hạn hoặc với các trường XML hoặc JSON.

Một tùy chọn khác với lược đồ này là bạn có thể xác định các mẫu, ví dụ: bạn có thể thêm một bảng mới BrandAttrTem mẫu. Mỗi khi bạn thêm một bản ghi mới, bạn có thể sử dụng trình kích hoạt hoặc SP để tạo một tập hợp các thuộc tính được xác định trước cho Chi nhánh này.

Tôi xin lỗi, tôi muốn mở rộng lời giải thích của mình bởi tôi nghĩ nó rõ ràng hơn tiếng Anh của tôi.

Cập nhật

Câu trả lời hiện tại của tôi sẽ hoạt động trên bất kể RDBMS nào. Theo nhận xét của bạn, nếu bạn cần lọc các giá trị thuộc tính, tôi sẽ đề xuất các thay đổi nhỏ.

Theo như MS-Sql không cho phép mảng, tôi đã thiết lập một mẫu mới duy trì cùng một lược đồ bảng, nhưng thay đổi AttrValue thành loại trường ARRAY.

Trong thực tế, bằng cách sử dụng POSTGRES, bạn có thể tận dụng lợi thế của mảng này bằng chỉ mục GIN.

(Hãy để tôi nói rằng @EvanCarrol có kiến ​​thức tốt về Postgres, chắc chắn tốt hơn tôi. Nhưng hãy để tôi thêm bit của mình.)

CREATE TABLE BCAttributes
(
BrandId int NOT NULL REFERENCES Brands(BrandId),
ClothesId int NOT NULL REFERENCES Clothes(ClothesId),
AttrId int NOT NULL REFERENCES Attrib(AttrId),
AttrValue text[],
PRIMARY KEY (BrandId, ClothesId, AttrId)
);

CREATE INDEX ix_attributes on BCAttributes(ClothesId, BrandId, AttrId);
CREATE INDEX ix_gin_attributes on BCAttributes using GIN (AttrValue);


INSERT INTO BCAttributes VALUES
(1, 1, 1, '{Blue, Red, White}'),
(1, 1, 2, '{32, 33, 34}'),
(1, 2, 1, '{Pearl, Black widow}'),
(1, 2, 2, '{M, L, XL}'),
(2, 1, 4, '{Levis, G-Star, Armani}'),
(2, 1, 3, '{Slim fit, Regular fit, Custom fit}'),
(2, 2, 4, '{G-Star, Armani}'),
(2, 2, 3, '{Slim fit, Regular fit}'),
(2, 2, 0, '{15% Discount}');

Bây giờ, bạn có thể truy vấn bổ sung bằng các giá trị thuộc tính riêng lẻ như:

Cho tôi một danh sách tất cả quần Kích thước: 33

AttribId = 2 AND ARRAY['33'] && bca.AttrValue

SELECT     c.ClothesName, b.BrandName, a.AttrName, array_to_string(bca.AttrValue, ', ')
FROM       BCAttributes bca
INNER JOIN BrandsClothes bc
ON         bc.BrandId = bca.BrandId
AND        bc.ClothesId = bca.ClothesId
INNER JOIN Brands b
ON         b.BrandId = bc.BrandId
INNER JOIN Clothes c
ON         c.ClothesId = bc.ClothesId
INNER JOIN Attrib a
ON         a.AttrId = bca.AttrId
WHERE      bca.AttrId = 2
AND        ARRAY['33'] && bca.AttrValue
ORDER BY   bca.ClothesId, bca.BrandId, bca.AttrId;

Đây là kết quả:

clothes name | brand name | attribute | values 
------------- ------------ ----------  ---------------- 
Pants          Brand1       Size        32, 33, 34

Tôi thực sự thích lời giải thích này, nhưng có vẻ như chúng ta chỉ đang trao đổi một lược đồ nhiều bảng để có nhiều CSV đó trong một cột - nếu điều đó có ý nghĩa. Mặt khác, tôi cảm thấy như tôi thích cách tiếp cận này hơn vì nó không yêu cầu thay đổi lược đồ, nhưng một lần nữa, nó chỉ cảm thấy như chúng ta đang đẩy vấn đề đi nơi khác (cụ thể là có các cột có độ dài thay đổi). Đây có thể là một vấn đề; Nếu tôi muốn truy vấn quần cỡ 3 trong DB thì sao? Có lẽ không có một giải pháp tốt đẹp nào cho vấn đề này. Có một tên cho khái niệm này để tôi có thể nhìn vào nó nhiều hơn?
youngrrrr

Trên thực tế ... để trả lời vấn đề tôi đặt ra, có lẽ câu trả lời có thể được mượn từ giải pháp của @ EvanCarroll: cụ thể là bằng cách sử dụng các loại jsonb thay vì chỉ đơn giản là VĂN / CHUẨN ở định dạng CSV. Nhưng một lần nữa - nếu có một tên cho khái niệm này, xin vui lòng cho tôi biết!
youngrrrr

1
Đó là một loại giá trị thuộc tính của thực thể. Đó không phải là một sự thỏa hiệp xấu giữa hiệu suất và thiết kế tốt. Đó là một sự đánh đổi, mặc dù. Bạn trao đổi một số hiệu suất cho một thiết kế sạch hơn, không bị vấy bẩn bởi các bảng "Brand_X" vô tận. Hình phạt hiệu suất, đi từ hướng phổ biến nhất đã nêu của bạn nên được tối thiểu. Đi theo con đường khác sẽ đau đớn hơn, nhưng đó là sự thỏa hiệp. vi.wikipedia.org/wiki/ Kẻ
Jonathan Fite

4

Những gì bạn đang mô tả là, ít nhất là một phần, một danh mục sản phẩm. Bạn có một số thuộc tính chung cho tất cả các sản phẩm. Những thứ này thuộc về một bảng chuẩn hóa tốt.

Ngoài ra, bạn có một loạt các thuộc tính dành riêng cho thương hiệu (và tôi mong đợi có thể là sản phẩm cụ thể). Hệ thống của bạn cần làm gì với các thuộc tính cụ thể này? Bạn có logic kinh doanh phụ thuộc vào lược đồ của các thuộc tính này hay bạn chỉ liệt kê chúng trong một loạt các cặp "nhãn": "value"?

Các câu trả lời khác đang đề xuất sử dụng cách tiếp cận CSV thực chất (cho dù đây là JSONhoặcARRAY cách khác) - Những cách tiếp cận này đã đề cập đến việc xử lý lược đồ quan hệ thường xuyên bằng cách di chuyển lược đồ ra khỏi siêu dữ liệu và vào chính dữ liệu.

Có một mẫu thiết kế di động cho điều này rất phù hợp với cơ sở dữ liệu quan hệ. Đó là EAV (thực thể-thuộc tính-giá trị). Tôi chắc rằng bạn đã đọc ở nhiều nơi, nhiều nơi rằng "EAV là Ác" (và nó là). Tuy nhiên, có một ứng dụng cụ thể trong đó các vấn đề với EAV không quan trọng và đó là danh mục thuộc tính sản phẩm.

Tất cả các đối số thông thường chống lại EAV không áp dụng cho danh mục tính năng sản phẩm, vì các giá trị tính năng của sản phẩm thường chỉ được lấy lại trong danh sách hoặc trường hợp xấu nhất vào bảng so sánh.

Việc sử dụng một JSONloại cột sẽ giúp bạn có khả năng thực thi bất kỳ ràng buộc dữ liệu nào khỏi cơ sở dữ liệu và buộc nó vào logic ứng dụng của bạn. Ngoài ra, sử dụng một bảng thuộc tính cho mỗi thương hiệu có những nhược điểm sau:

  • Nó không có quy mô tốt nếu cuối cùng bạn có hàng trăm nhãn hiệu (hoặc nhiều hơn).
  • Nếu bạn thay đổi các thuộc tính được phép trên một thương hiệu, bạn phải thay đổi định nghĩa bảng thay vì chỉ thêm hoặc xóa các hàng trong bảng điều khiển trường thương hiệu.
  • Bạn vẫn có thể kết thúc với các bảng dân cư thưa thớt nếu thương hiệu có nhiều tính năng tiềm năng, chỉ có một tập hợp nhỏ trong số đó được biết đến.

Không khó để lấy dữ liệu về một sản phẩm có tính năng dành riêng cho thương hiệu. Có thể dễ dàng tạo ra một SQL động bằng cách sử dụng mô hình EAV so với việc sử dụng mô hình bảng cho mỗi loại. Trong bảng mỗi loại, bạn cần phản ánh (hoặc của bạn JSON) để tìm hiểu tên cột tính năng là gì. Sau đó, bạn có thể xây dựng một danh sách các mục cho mệnh đề where. Trong mô hình EAV, WHERE X AND Y AND Ztrở thành INNER JOIN X INNER JOIN Y INNER JOIN Z, do đó, truy vấn phức tạp hơn một chút, nhưng logic để xây dựng truy vấn vẫn hoàn toàn dựa trên bảng và nó sẽ đủ khả năng mở rộng nếu bạn có các chỉ mục thích hợp được xây dựng.

Có rất nhiều lý do để không sử dụng EAV như một cách tiếp cận chung. Những lý do đó không áp dụng cho danh mục tính năng sản phẩm nên không có gì sai với EAV trong ứng dụng cụ thể này.

Để chắc chắn, đây là một câu trả lời ngắn cho một chủ đề phức tạp và gây tranh cãi. Tôi đã trả lời các câu hỏi tương tự trước đây và đi sâu vào chi tiết hơn về ác cảm chung với EAV. Ví dụ:

Tôi có thể nói rằng EAV được sử dụng ít thường xuyên hơn so với trước đây, vì những lý do chủ yếu là tốt. Tuy nhiên, tôi nghĩ nó cũng không được hiểu rõ.


3

Đây là vấn đề của tôi: các nhãn hiệu quần áo khác nhau đòi hỏi thông tin khác nhau. Thực hành tốt nhất để xử lý một vấn đề như thế này là gì?

Sử dụng JSON và PostgreSQL

Tôi nghĩ rằng bạn đang làm điều này khó hơn mức cần thiết và bạn sẽ bị cắn sau đó. Bạn không cần mô hình giá trị thuộc tính Entity của trừ khi bạn thực sự cần EAV.

CREATE TABLE brands (
  brand_id     serial PRIMARY KEY,
  brand_name   text,
  attributes   jsonb
);
CREATE TABLE clothes (
  clothes_id   serial        PRIMARY KEY,
  brand_id     int           NOT NULL REFERENCES brands,
  clothes_name text          NOT NULL,
  color        text,
  price        numeric(5,2)  NOT NULL
);

Hoàn toàn không có gì sai với lược đồ này.

INSERT INTO brands (brand_name, attributes)
VALUES
  ( 'Gucci', $${"luxury": true, "products": ["purses", "tawdry bougie thing"]}$$ ),
  ( 'Hugo Boss', $${"origin": "Germany", "known_for": "Designing uniforms"}$$ ),
  ( 'Louis Vuitton', $${"origin": "France", "known_for": "Designer Purses"}$$ ),
  ( 'Coco Chanel', $${"known_for": "Spying", "smells_like": "Banana", "luxury": true}$$ )
;

INSERT INTO clothes (brand_id, clothes_name, color, price) VALUES
  ( 1, 'Purse', 'orange', 100 ),
  ( 2, 'Underwear', 'Gray', 10 ),
  ( 2, 'Boxers', 'Gray', 10 ),
  ( 3, 'Purse with Roman Numbers', 'Brown', 10 ),
  ( 4, 'Spray', 'Clear', 100 )
;

Bây giờ bạn có thể truy vấn nó bằng cách tham gia đơn giản

SELECT *
FROM brands
JOIN clothes
  USING (brand_id);

Và bất kỳ toán tử JSON nào cũng hoạt động trong mệnh đề where.

SELECT *
FROM brands
JOIN clothes
  USING (brand_id)
WHERE attributes->>'known_for' ILIKE '%Design%';

Là một lưu ý phụ, không đặt các url trong cơ sở dữ liệu. Họ thay đổi theo thời gian. Đơn giản chỉ cần tạo một chức năng mà có chúng.

generate_url_brand( brand_id );
generate_url_clothes( clothes_id );

hay bất cứ cái gì. Nếu bạn đang sử dụng PostgreSQL, bạn thậm chí có thể sử dụng hàm băm .

Cũng cần lưu ý đặc biệt, jsonbđược lưu trữ dưới dạng nhị phân (do đó là -'b ') và nó cũng có khả năng lập chỉ mục, hoặc SARGable hoặc bất cứ thứ gì khác mà những đứa trẻ tuyệt vời đang gọi nó trong những ngày này:CREATE INDEX ON brands USING gin ( attributes );

Sự khác biệt ở đây là ở sự đơn giản của truy vấn ..

Cho tôi tất cả quần áo của Brand2

SELECT * FROM clothes WHERE brand_id = 2;

Đưa cho tôi tất cả Quần áo có thuộc tính: Kích thước

SELECT * FROM clothes WHERE attributes ? 'size';

Làm thế nào về một khác nhau ..

Cung cấp cho tôi tất cả quần áo và thuộc tính cho bất kỳ quần áo có sẵn lớn.

SELECT * FROM clothes WHERE attributes->>'size' = 'large';

Vì vậy, nếu tôi hiểu chính xác, ý chính của những gì bạn nói là nếu có mối quan hệ giữa các nhãn hiệu và thuộc tính (nghĩa là nó có hợp lệ hay không) thì giải pháp của McNets sẽ được ưu tiên (nhưng các truy vấn sẽ tốn kém hơn / chậm hơn). Mặt khác, nếu mối quan hệ này không quan trọng / thêm "ad-hoc", thì người ta có thể thích giải pháp của bạn hơn. Bạn có thể giải thích thêm một chút bằng ý của bạn khi bạn nói "tôi sẽ không bao giờ sử dụng nó với PostgreQuery không?" Dường như không có một lời giải thích cho nhận xét đó. Xin lỗi cho tất cả các câu hỏi!! Tôi thực sự đánh giá cao câu trả lời của bạn cho đến nay :)
youngrrrr

1
Rõ ràng có một mối quan hệ, câu hỏi duy nhất là bạn cần bao nhiêu để quản lý nó. Nếu tôi đang sử dụng một thuật ngữ mơ hồ như thuộc tính , thuộc tính hoặc tương tự, tôi thường có ý nói rằng nó khá đặc biệt hoặc không có cấu trúc cao. Vì thế, JSONB chỉ tốt hơn vì đơn giản hơn. bạn có thể tìm thấy bài đăng này thông tin coussej.github.io/2016/01/14/14
Evan Carroll

-1

Một giải pháp dễ dàng là bao gồm tất cả các thuộc tính có thể dưới dạng cột trên bảng quần áo chính và làm cho tất cả các cột cụ thể của thương hiệu không thể bị xóa. Giải pháp này phá vỡ chuẩn hóa cơ sở dữ liệu, nhưng rất dễ thực hiện.


Tôi nghĩ rằng .. Tôi có một ý tưởng về những gì bạn đang nói, nhưng nó có thể hữu ích để bao gồm nhiều chi tiết hơn và có lẽ là một ví dụ là tốt.
youngrrrr
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.