MariaDB has it readily available, and also has many improvements over MySQL and Postgres, especially for NoSQL features and scalability. There's even a third, albeit a little more "manual" implementation here, the graph relationship in which you can model data, in which you can easily model event-driven documents, like a Purchase that goes from "a customer" to "a store", which you can later use for much easier and deep analytics than with the classical SQL stance. Like using references to relate a User to a Profile, and an embed to relate a Product to an Order. You have two de facto ways to connect data, by reference and embedding, which in Ecommerce, both have big uses. But then, I have the same user in the Profile service, with the same id, but totally different fields. For instance, I've got a User service that has all auth related information of a user. What you need to see is to model your data in a way that makes sense with Mongo.
Whatever Postgres offers, Mongo does it a little easier and better, like text search and geo-queries.
Not just because of it being NoSQL, but because all of the support I find in the NodeJS community through packages and utilities that make it dead easy to use it for several use-cases. Now-a-days, I really found my solution in Mongo. One of the main challenges with analyzing a NoSQL database being familiar in the SQL ways, is that it's easy to look for "analogies" for what makes SQL useful, like relationship enforcing, transactions and the cascading effect on deletes, updates and inserts, and that limit your vision a lot when analyzing a tool like Mongo, especially in a micro-services pattern. However, frankly, I didn't want to model statically all data, since I have several distinct schemas (like for different product types) and I wanted some flexibility to add or remove as I saw fit. A few months ago, I had decided to use Postgres because since its version 9 it showed a lot of progress for being a high-availability database.
0 kommentar(er)
