CODEWITHSUNDEEP
databasedatabase-design
uksz
uksz

Reputation: 18699

Using proper relations for product and attribute

I am about to implement a database for simple ecommerce platform. I want to implement the following:

What relations should I use to store this kind of information?

Upvotes: 1

Views: 174

Answers (2)

Damir Sudarevic
Damir Sudarevic

Reputation: 22187

Here is the logical model -- the way I understood it; you should be able to tweak it.

From this you can derive the physical model and the SQL code. The word KEY here means UNIQUE NOT NULL and you may use them for primary keys. Should you choose to introduce integers as primary keys, make sure you keep these UNIQUE.

Note that everything should be NOT NULL, once you get to the SQL.

Category named (CAT) exists. 

Category {CAT}
     KEY {CAT}

Attribute named (ATR) exists. 

Attribute {ATR}
      KEY {ATR}

Category (CAT) has attribute (ATR).

Each category has more than one attribute, it is possible for the same attribute to belong to more than one category.

CategoryAttribute {CAT, ATR}
              KEY {CAT, ATR}

Product named (PRD) belongs to category (CAT).

Each product belongs to exactly one category, each category may have more than one product.

 ProductCategory {PRD, CAT}
             KEY {PRD}
             KEY {PRD, CAT} -- seems redundant here, but is
                            -- needed for the FK from the next table

     FOREIGN KEY {CAT} REFERENCES Category {CAT}

Product (PRD) from category (CAT) has attribute (ATR) that belongs to that category.

For each attribute that belongs to a category, that attribute may belong to more than one product from that category.

ProductCategoryAttribute {PRD, CAT, ATR}

        KEY {PRD, CAT, ATR}
FOREIGN KEY {PRD, CAT} REFERENCES ProductCategory   {PRD, CAT}
FOREIGN KEY {CAT, ATR} REFERENCES CategoryAttribute {CAT, ATR}

Upvotes: 1

Sklivvz
Sklivvz

Reputation: 31133

I don't know what database platform you are using, but for small numbers of products, and for queries that do not depend on the value of the per-category attributes, I'd use the following strategy:

CREATE TABLE "Category" (
  "id" INTEGER PRIMARY KEY AUTOINCREMENT
);

CREATE TABLE "Product" (
  "id" INTEGER PRIMARY KEY AUTOINCREMENT,
  "categoryId" INTEGER NOT NULL REFERENCES "Category" ("id"),
  "attributes" TEXT NOT NULL
);

ER 1

In this example, the categories are used mainly to enforce referential integrity and to provide a list of categories for navigation.

The attributes are stored inside the attributes column as JSON (most modern databases tend to support this natively).

If there are any attributes common to all types of products, we'd create specific columns in Product. For example, you could add creationDate, deletionDate, price, or whatnot.

This allows you to perform the typical Select * From Product Where id = @Id to get a specific product and Select * From Product Where categoryId = @CategoryId to get all products in a category.

A creationDate could be useful to sort the products by creation date and take the top N, if necessary, when filtering by category. However with small quantities like thousands of products you might as well get all products by category and do this in code.

Regarding the code aspect, products like Dapper have specific extensions helping you deal with these discriminated unions, but writing code to support it is fairly easy. Here's an how. I'll write pseudo-C#, but I'm sure you can adapt.

We have an abstract class taking care of the Product table rows

public abstract class ProductBase
{

   // only the fields in the Product table here

   public int CategoryId { get; set; }
   protected string Attributes { get; set; }

   // serialize extra fields to JSON in Attributes
   protected abstract void Prepare();

   // load the common fields from a data row
   protected static ProductBase(DataRow dr)
   {
      CategoryId = int.Parse(dr["categoryId"]);
      Attributes = dr["attributes"] as string;
   }

   // save to DB
   public void Save()
   {
      Prepare();

      // save to SQL
   }
}

We also have specific classes per category which have the extra attributes and handle serialization and deserialization.

public class FooProduct: ProductBase
{
   public string Color { get; set; }

   protected override void Prepare()
   {
      Attributes = Json.Serialize(new { Color });
   }

   public FooProduct(DataRow dr): base(dr)
   {
      // we can only create foo products if the category is foo
      if (CategoryId != 23) throw new InvalidOperationException();

      var attr = Json.Deserialize(Attributes);
      Color = attr.Color;
   }
}

This idea works great while you don't need to get the "foo" products by Color. If you can afford to get all "foo" products and filter in code, great. If your database understands JSON and lets you query inside the Attributes field, good it will get slow with large numbers unless the server allows indexes to reference JSON-serialized values.

If all else fails, you'll need to create an index table which contains the color values and the ids of the products which have that color. This is relatively painful and you don't want to do it unless you need it (and you don't right now).

Upvotes: 0

Related Questions