docs.reactioncommerce.com/reaction-docs/master/fa…
I found the following on the reactioncommerce docs:
Is MongoDB/NoSQL best suited for ecommerce?
We think so! We believe that the common SQL schema for legacy ecommerce platforms isn’t just >unnecessary; it’s overkill. By rethinking the way the database is architected, there are numerous >benefits of Mongo/NoSQL – from speed to simplified code.
We enforce all of the typical joins, cascades, schemas, validation, etc., with functionality that we >have included (collections, schemas, hooks, helpers). But instead of trying to join a bunch of stuff >together, we simply have an object that is a product. There are huge advantages to this >approach, such as speed + easy code + the schema can be easily modified to accommodate any >data requirements. This is unlike legacy platforms and their use of the entity - attribute - value >lookup that is so complex and slow. In fact, legacy platforms have tried to architect their way >around these very real limitations of SQL that NoSQL easily handles (using EAV). By using NoSQL, >we remove the very complex layer of looking up and joining attributes, and also the complexity >of adding new field/values. (You just do it to the main object, and that’s going to persist >throughout the life of the object.) We also don’t have to deal with the continuous translation of >database structure to a code object.
In reality, in our use, the DB is just the persistent storage of the JavaScript objects. For example, a >product is a collection of variants (objects) like blue, green, etc., and are each their own object >contained within a “product” object.
In localization (l10n), this can also mean different pricing, taxes, etc., for different regions, so >pricing is at the variant level not at the product level. This is even true with just one language >when you have “Blue XXL” being more expensive than “Green XL.”