Data Modeling  with diferents entities

Good night guys,

I want to create a pizza ordering system.

I am having trouble modeling the data so that it is saved correctly in the database and presented to the user.

I have in mind a "pizza" record with:

1. flavor

2. small size price

3. medium size price.

4. price for large size.

Do I need to create three entities: one with flavor, one with size and one with value?

And how to make the aggregates in the preparation?



Hi Davi Matsuo,

If those are characteristics of a Pizza (for you), then you would add them directly as attributes of a single Pizza entity.

If flavor can be one of several predefined options (e.g. Margherita, Four Cheeses, Calzone, etc...) then you may want to create a Flavor static entity as well (with one record for each option available), and on the Pizza entity add an attribute of type Flavor Identifier.

As for the Size vs. Price... the way you defined it, it's confusing two different relationships. Your ValorId attribute in Pizza shouldn't be there (it's creating an unwanted one-to-many relationship between a price-for-specific-size and a Pizza definition). The Price entity itself already establishes a many-to-many relationship between Pizza and Size, qualified by the actual price of that pizza at that size.

Hope this helps!

Hi Davi Matsuo, 

You can create a static entity for flavor and size and one master entity to store all details related to order and take the reference of these static entities. I think the price should not be kept in a static entity because the price can be change



Thanks guys,

I will try to implement your suggestions. 

Hi @Davi Matsuo 

You can implement something like this

In this way, the entity pizza will store a price of a pizza by flavor and by size.

Hope this helps


Gonçalo Almeida


Perfect One! @Goncalo Almeida 

Hi Gonçalo,

Thank you so much.

I will try to do this. 

Sorry for the late reply!

See ya!



Gonçalo Almeida

I'm not sure creating static entities is the best solution.

If later on you decide to, lets say, add a new flavor you must change the code adding a new record to the 'Pizza_flavor' entity and publish the module. In my opinion they all should be regular entities with screens to configure (CRUD).

Hello @Joao Melo 

My schema's just a guideline.

Now it needs to be applied according to the use case. There are several possibilities and all are correct


Gonçalo Almeida

Hi Gonçalo.

I perfectly understand your suggestion as a guideline. And it's a quick and seemly solution.

But, as Davi himself admits, he is not the best at data modeling. That was why I suggested that he should implement with regular entities rather than static entities. That way his base model is more flexible and ready to scale up.


Hi everyone,

I’d recommend keeping with Static Entities. It’s easier to think about and have a working system. Later on, if Davi needs the flexibility of a standard Entity it is easy to convert from Static Entity to regular Entity via a context-menu entry that does that magic for you (right click on your Entity and check Advanced): best of both worlds, simplicity of Static Entities without compromising future flexibility.

Hope this helps!

I'd undestood. I really trying. I'm not a good to modeling data. And I don't have much time to practice and study. But what you say make sense, I need a form to create and edit the pizzas.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.