Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would suggest the following database/object structure:</p> <pre><code>[Auction] n..1 [Category] 1..n [Variation Attribute] 1..n [Attribute Value] </code></pre> <p>An auction then has a category and several attribute values referring the variation attribute as well:</p> <pre><code>[Auction] = [Category], [Name], [Description] [Auction_AttrVal] = [AuctionID], [VarAttrID], [AttrValID] </code></pre> <p>First of all you can have some kind of category table, which holds items like "Paintings", "Clothes", "Computers". An auction / product is assigned to one category.</p> <p>Each category then defines variation attributes for this specific category. An example would be "Size" for the category "Clothes" or "CPU" for the category "Computers". You can also add predefined values for the variation attributes to limit the number of variations and avoid differentiations like "3GhZ" vs "3 GhZ".</p> <p>This mechanism also allows for easy filtering of search results. You select a category and simply load all variation attributes as filters (or add a flag to an attribute to declare it as such) and offer the values for filtering to the end-user.</p> <p>Furthermore you can make variation attributes for a category mandatory to force users who create the auctions (I'm assuming it's Consumer-to-Consumer) to provide sufficient information for their auction. </p> <p>The code will probably be quite generic and simple. The database structure is highly flexible and extensible. Performance is much better than having all in one table. You probably should create an index (for the field <code>AuctionID</code>) for the <code>Auction_AttrVal</code> table. Please let me know if the database structure is not explained properly.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to build database for variant management in a webshop
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USPeter Ilfrich
    1. USPeter Ilfrich
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI have the problem, that under "categories" there can be both e.g. t-shirts and jeans which should have different sizes. Maybe this could be solved by children categories, but isn't it possible to make the differentiations variable for each product but still in some way "connected" to the other to make a trimmed and nice way of the calues (your "3GhZ" vs "3 GhZ" is exactly a thing I will avoid)
      singulars
      1. PO
      1. USdenlau
    2. COYou can make parent categories. You assign the auction to the lowest category level (e.g. if you have "Clothes" as parent and "Jeans" as subcategory you assign to "Jeans", which implies the assignment to "Clothes"). Each level can define different variation attributes. When you create the auction you simply move up the hierarchy and add all attributes. This would also allow you to override attributes of the parent by giving it the same name and then on the way up the hierarchy check if the attribute was already mentioned. Simply add a ParentCategoryID (which can be null) to the Category table.
      singulars
      1. PO
      1. USPeter Ilfrich
    3. COTo be more specific about the overriding: let's say Clothes define a size (XXL, XL, L, M, S, XS). Jeans however measure in 32/32, 34/32, ... You define the variation attribute "Size" for "Clothes" with values (XXL, XL, ...) and for Jeans with different values (32/32, ...). When you define the options for the user, you find "Size" for "Jeans" first and add it as parameter. Then when you encounter "Size" again for "Clothes" you simply ignore it.
      singulars
      1. PO
      1. USPeter Ilfrich
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload