Multi levels

Requirements

• You have read the Glossary
• You have read the Basics

What you will learn

How to model 1 to N relationship between items

Use cases

Concrete example

In apparel sector, each product have a model, each model is declined in colors and each colors is declined in size. You can represent items like this:

To model this in Product-Live we will create a new table, with three levels :

• Level 1 = Model
• Level 2 = Model color
• Level 3 = Article

Identifiers and Fields by levels (Identifiers and Fields are associated with one and only one level). Classification does not have Level associated because they can only be created in the first Level.

A Screen for each Level (a screen is associated with one and only one Level). For simplicity we just have named Screens with the name of the Level.

Level = Model

In Product-Live when we select the screen Model we can view all the columns associated with the Level Model:

In this example we only have created two items at the Level Model. Items at the Level Model are uniquely identified by an Identifier named Reference.

Other attributes at level Model:

• Typology (Classification)
• Title EN (Field single line text)
• Title FR (Field single line text)
• Description EN (Field long text)
• Description FR (Field long text)
• Life cycle model (Field single select)

Fields specific to Typology = Apparel:

• Gender (Field single select)

Fields specific to Typology = Dress:

• Gender (Field single select)
• Sleeve length (Field single select)
• Motherhood (Field single select)

Level = Model color

In the Level Model color we can view/filter/sort the attributes of the level Model and view/filter/sort the attributes of the level Model color. Notice that the line height of the Screen is taller because images are managed at the level model color and it is a best practice to set a taller line height when dealing with images.

Each item of the Level Model color is uniquely identified by an Identifier named Reference color.

The attributes of the level Model are not editable and repeated on each line, but they can be filtered or sorted. You can simply filter all items with Typology = Dress (Level Model) and Color = Red (Level Model color)

Attributes at level Model color:

• Main color (Field single select)
• Life cycle model color (Field single select)
• Main material (Field single select)
• Composition EN (Field long text)
• Composition FR (Field long text)
• Composition detail (Field multiple select quantified)
• Instructions (Field multiple select)
• Main Image (Field image)
• Back (Field image)
• Front (Field image)
• Packshot (Field image)
• Zoom (Field image)

Best practice

Here we have set attributes images common to all categories, but if you are dealing with large typology of products, it is a best practice to set images specific to categories.

Level = Article

If you have understand the level Model color, it's exactly the same idea. We just have added attributes specific to the level article:

• Size (Field single select)
• Life cycle article (Field single select)
• Stock (Field number)
• Price (Field number)

Each item at the level Article is uniquely identified by an Identifier EAN 13 or SKU.

What are the advantages to use multi-levels?

If you do not have multiple-levels in the example above, you are only dealing with the level Article. Imagine the number of duplicate values that you will have to face of, imagine the number of typing errors that you can do.

So multi-levels is a very powerful solution to improve your data quality and readability.

When to use multi levels and when not?

When to use?

Multiple levels must be used when the children item must be deleted when the parent item is deleted.

In the example above, if we delete an item at the level Model, all its children at the levels Model color and Article must also be deleted.

Another concrete use case would be an Orders table:

• Level 1: Order
• Level 2: Order detail

Attributes at Level 1 = Order:

• Order number
• Datetime

Attributes at Level 2 = Order detail

• EAN 13
• Quantity
• Price

In this example, if an order is deleted, all order details must also be deleted.

When not to use?

Let's say that you want to model products and pricing by suppliers. Each products can have one or many pricing by supplier. So here we have a 1 to N relation.

You might be tempted to create a products table with a level 2 for pricing by suppliers. But you should ask yourself: does deleting a product must also delete the pricing associated? The answer is no, you should want to keep the history of all pricing regardless if the product still exist in the products table.

So in that case you must create a relation between two tables:

• Table Products
• Table Pricing

It will be detailed in another tutorial.

What does it look like in the API?

View schema example

@code

View items example

@code