Saya pribadi tidak suka menggunakan skema multi-tabel untuk tujuan ini.
- Sulit untuk memastikan integritas.
- Sulit dipertahankan.
- Sulit untuk menyaring hasil.
Saya telah menetapkan sampel dbfiddle .
Skema tabel yang saya usulkan:
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)
);
Biarkan saya memasukkan beberapa data:
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');
Jika Anda perlu mengambil atribut umum:
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
Atau Anda dapat dengan mudah mendapatkan Pakaian dengan Merek:
Beri aku semua pakaian 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
Tetapi bagi saya, salah satu yang terbaik dari skema ini adalah Anda dapat memfilter berdasarkan Attibutes:
Beri aku semua Pakaian yang memiliki atribut: Ukuran
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
Menggunakan skema multi-tabel apa pun dari permintaan sebelumnya akan perlu berurusan dengan jumlah tabel yang tidak terbatas, atau dengan bidang XML atau JSON.
Opsi lain dengan skema ini, adalah bahwa Anda dapat menentukan template, misalnya, Anda bisa menambahkan tabel baru BrandAttrTemplates. Setiap kali Anda menambahkan catatan baru Anda bisa menggunakan pemicu atau SP untuk menghasilkan sekumpulan atribut yang telah ditentukan untuk Cabang ini.
Maaf, saya ingin memperluas penjelasan saya dengan saya pikir itu lebih jelas daripada bahasa Inggris saya.
Memperbarui
Jawaban saya saat ini harus bekerja pada RDBMS apa pun. Menurut komentar Anda, jika Anda perlu memfilter nilai atribut saya sarankan perubahan kecil.
Sejauh MS-Sql tidak mengizinkan array, saya telah menyiapkan sampel baru mempertahankan skema tabel yang sama, tetapi mengubah AttrValue menjadi tipe bidang ARRAY.
Bahkan, menggunakan POSTGRES, Anda dapat memanfaatkan array ini menggunakan indeks GIN.
(Izinkan saya mengatakan bahwa @EvanCarrol memiliki pengetahuan yang baik tentang Postgres, tentunya lebih baik dari saya. Tetapi izinkan saya menambahkan bagian saya.)
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}');
Sekarang, Anda juga dapat melakukan kueri menggunakan nilai atribut individual seperti:
Beri saya daftar semua celana Ukuran: 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;
Ini hasilnya:
clothes name | brand name | attribute | values
------------- ------------ ---------- ----------------
Pants Brand1 Size 32, 33, 34
Apa yang Anda gambarkan adalah, setidaknya sebagian, katalog produk. Anda memiliki beberapa atribut yang umum untuk semua produk. Ini termasuk dalam tabel yang dinormalisasi dengan baik.
Di luar itu, Anda memiliki serangkaian atribut yang spesifik merek (dan saya harapkan bisa spesifik produk). Apa yang perlu dilakukan sistem Anda dengan atribut spesifik ini? Apakah Anda memiliki logika bisnis yang bergantung pada skema atribut ini atau Anda hanya mencantumkannya dalam serangkaian pasangan "label": "nilai"?
Jawaban lain menyarankan menggunakan apa yang pada dasarnya pendekatan CSV (apakah ini
JSONatauARRAYatau sebaliknya) - ini pendekatan mengorbankan skema relasional biasa menangani dengan memindahkan skema dari metadata dan ke dalam data itu sendiri.Ada pola desain portabel untuk ini yang sangat cocok dengan basis data relasional. Itu adalah EAV (entitas-atribut-nilai). Saya yakin Anda telah membaca di banyak tempat "EAV is Evil" (dan memang demikian). Namun, ada satu aplikasi khusus di mana masalah dengan EAV tidak penting, dan itu adalah katalog atribut produk.
Semua argumen biasa terhadap EAV tidak berlaku untuk katalog fitur produk, karena nilai-nilai fitur produk umumnya hanya dimuntahkan ke dalam daftar atau kasus terburuk ke dalam tabel perbandingan.
Menggunakan
JSONtipe kolom membutuhkan kemampuan Anda untuk menegakkan batasan data apa pun dari database dan memaksanya ke dalam logika aplikasi Anda. Juga, menggunakan satu tabel atribut untuk setiap merek memiliki kelemahan berikut:Tidak terlalu sulit untuk mengambil data tentang suatu produk dengan fitur-fitur khusus merek. Mungkin lebih mudah untuk membuat SQL dinamis menggunakan model EAV daripada menggunakan model tabel-per-kategori. Dalam tabel-per-kategori, Anda perlu refleksi (atau Anda
JSON) untuk mencari tahu apa nama kolom fitur. Kemudian Anda bisa membuat daftar item untuk klausa tempat. Dalam model EAV,WHERE X AND Y AND ZmenjadiINNER JOIN X INNER JOIN Y INNER JOIN Z, jadi kueri sedikit lebih rumit, tetapi logika untuk membangun kueri masih sepenuhnya didorong oleh tabel dan itu akan lebih dari cukup terukur jika Anda memiliki indeks yang tepat dibangun.Ada banyak alasan untuk tidak menggunakan EAV sebagai pendekatan umum. Alasan-alasan itu tidak berlaku untuk katalog fitur produk sehingga tidak ada yang salah dengan EAV dalam aplikasi spesifik ini.
Yang pasti, ini adalah jawaban singkat untuk topik yang kompleks dan kontroversial. Saya telah menjawab pertanyaan serupa sebelumnya dan membahas lebih detail tentang penolakan umum terhadap EAV. Sebagai contoh:
Saya akan mengatakan EAV digunakan lebih jarang akhir-akhir ini daripada dulu, karena sebagian besar alasan bagus. Namun, saya pikir itu juga tidak dipahami dengan baik.
sumber
Menggunakan JSON dan PostgreSQL
Saya pikir Anda membuat ini lebih sulit dari yang seharusnya dan Anda akan digigitnya nanti. Anda tidak perlu model nilai Entitas – atribut-nilai kecuali Anda benar-benar membutuhkan EAV.
Sama sekali tidak ada yang salah dengan skema ini.
Sekarang Anda dapat menanyakannya menggunakan gabungan sederhana
Dan salah satu operator JSON bekerja di mana klausa.
Sebagai catatan tambahan, jangan taruh url di database. Mereka berubah seiring waktu. Cukup buat fungsi yang membawanya.
atau terserah. Jika Anda menggunakan PostgreSQL Anda bahkan dapat menggunakan hashids .
Juga dari catatan khusus,
jsonbdisimpan sebagai biner (dengan demikian -'b ') dan juga dapat diindeks, atau SARGable atau apa pun yang disebut anak-anak keren hari ini:CREATE INDEX ON brands USING gin ( attributes );Perbedaannya di sini adalah kesederhanaan kueri ..
Bagaimana dengan yang berbeda ..
sumber
Salah satu solusi mudah adalah dengan memasukkan semua atribut yang mungkin sebagai kolom pada tabel pakaian utama, dan membuat semua kolom khusus merek dapat dibatalkan. Solusi ini memecah normalisasi database, tetapi sangat mudah diimplementasikan.
sumber