Answer the question
In order to leave comments, you need to log in
Does this database organization scheme have the right to exist?
Hello!
I want to understand whether such a scheme has the right to exist and what are its obvious and implicit disadvantages.
Only the id is stored in the SQL database (possibly also numerical parameters, such as amount / quantity / etc.)
Everything else is stored in the NOSQL database.
That is (as an example), there is a "goods". in the SQL database for this product - only the ID column.
In the NOSQL database, all fields of this product are stored (of course, they can be different for different products).
SQL database is used for storage and selections with complex relationships.
PS That is, to put it simply, all the properties of an object are stored in NOSQL, and all actions with it are stored in SQL.
Does such a scheme have the right to exist and, if so, how is it most organic to use it with ActiveRecord?
Thanks in advance
Answer the question
In order to leave comments, you need to log in
It has the right to exist, but .... what's the point?
In general, the most common scheme is to store everything in a relational database and start aggregation in nosql by changing the data. In this case, we have a reliable storage that stores all the data, and a nosql database that stores data aggregations in order to speed up sampling through denormalization. In this case, there will be a lot of duplication in nosql, but this does not soar for us, since we have a relational database, from which it is always possible to file aggregations at least from scratch.
Accordingly, we have a division - all write operations work exclusively with relational, all read operations - with nosql (well, or part with nosql and part with relational, it depends on what you want to speed up and whether there is any sense in organizing data aggregation).
Any scheme has the right to life until it starts shamelessly slowing down. As already noted in the comments - Why? You actually instead of one request - do 2 and in different sources. What is stopping you from creating a products_description table and storing 3 fields in it - product_id , locale, and data in xml or json format? There are 2 parameters at the input - id and locale, at the output all the necessary data for building the form. And if at the database level it is not difficult to check the integrity of a foreign key, then how are you going to control the data in two different sources?
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question