3
I own several products and each one has its own characteristics, some have weight, some do not, some have extra fee and others do not, etc. Is it good practice to create a new table of product parameters and keep a JSON on each individual characteristic of each product? I don’t know any other way to do it.
3
Have you actually thought that you should not only use relational but also create another table? This is how the misuse of this Nosql starts, people look for a dusty problem and then think that the solution is to use something completely different that helps in this minimum detail and screws with everything else that helped you to use the relational.
And the AP is on the right track, seeing an obvious solution that people don’t see. If this data is essentially descriptive and varies, the relational has a simple solution, store it as descriptive data. Look how magical! And with the detail that some Dbms even have mechanisms that facilitate this and allow indexing normally of simple form (others need additional effort). It was not said in the question which database is being used, but if it is to exchange that it is a relational that helps to manipulate this situation well and not leave aside all advantages of relational by something so secondary. But even if the used DB is not ideal, it can still work well with this.
The solution is in the question, just use a JSON or a BSON or a JSONB or a YAML, or even XML (Argh), or whatever format you want to use of key and value with the specific characteristics of each product in a single document, some already use it natively, others will be treated as VARCHAR and you’ll have to create a few little functions to manipulate the data in a simpler way. What you can’t do is want to create fields for each feature as I’ve seen some people do, and then it gets horrible and one actually thinks that the only way to solve this is to go to Nosql. No, it’s not, just use the way schemaless that every relational allows to a greater or lesser degree. This is not a good reason to go to Nosql.
You want to put this on another table? Okay, it can, but looking over the top I don’t think it’s necessary and probably inappropriate, it’s wrong use of relational (unless I’ve got the problem wrong). Do it if you have a good reason. People make many decisions without having a good reason, for example to go to a Nosql, the only reason the person had was that they don’t know how to shape their problem well. There she has a bad model and inadequate mechanism.
What people don’t understand is that you can do in the relational the same as in the document model. The document model only has the advantage that it can scale horizontally in a simpler way (the relational gives more work, but also gives), while it gives up the consistency and integrity of data so important for most applications (even for generating duplicity, which is difficult to manage). In general who adopts Nosql usually makes the application give consistency, which is absurdly more difficult than anything you do in relational.
You may find it a little bit more work to have to manipulate this data in the relational, and this is true, a little yes, but in Nosql there is so much that is more work, just change of problem. I’m not saying there’s a point where Nosql isn’t more interesting, but it’s rare cases. And it also has certain patterns that maybe Nosql isn’t that much trouble, but they’re not typical applications. In general document models do not normalize data and manage non-standard data goes from difficult to insanity (so it has so much application that gives information completely non sense.
There are some cases that making a value key table relational way is worth it, but I doubt that’s the case. There is a time when you should abandon the relational model, but not the RDBMS (SGDBR) that knows how to work in a hybrid way. Who does not know to be hybrid is the typical Nosql (I know some Nosql who know, but are not the ones that people use, ironic).
In short:
It just scared me to tag DDD on the question, another thing that people adopt without having a clear reason that needs that. Then after the person adopts there is no turning back and have to pretend that is being good.
1
I would say that using a relational structure in this case would be bad, I would opt for a document-oriented database because in the same Center you could have documents with different structures.
Example Product Television:
Sony TV 4k Smart 55
Tv Lg Full HD 30
Note that the structure is different, Sony is smart and Lg is not.
In the case of relational database even when some attribute is not filled in the query it brings the empty attribute, in the non-relational database it is able to bring in the same query documents with different structures thus leaving the data reading much faster.
Browser other questions tagged modeling software-engineering software-architecture ddd
You are not signed in. Login or sign up in order to post.
Have you considered the possibility of using a non-relational bank?
– rray
So, I don’t know if it pays to use an entire nonrelational bank just to solve this...
– Danilo Tiago Thai Santos
You can use the interface to your do and store the data in a separate table,
produtos_parametros, that has a foreign key to the product record, the name and value of the parameter, in a 1:N relation. If this is the case, you can have another column indicating the type of the value of that parameter. In the products table you leave only information that is common to all.– Woss
@Danilotiagothaisantos Did any of the answers solve your question? Do you think you can accept one of them? Check out the [tour] how to do this, if you haven’t already done so. You would help the community by identifying what was the best solution for you. You can accept only one of them. But you can vote on any question or answer you find useful on the entire site
– Maniero