Partitioning and window functions will be great for your own use internally too, like answering questions of "What types of takeways perform the best for us, Italian, Mexican?" or in combination with PostGIS, answering questions like "What kind of takeways do we need to market to, to improve our selection?". for example will let you query for restaurants based on location, without the big cost that comes from constantly using something like Google Maps API to work out which restaurants are near to someone ordering. PostgreSQL also offers you some extensions, which are just amazing for your use-case. That to me suggests PostgreSQL, which will scale quite well if you database design is okay. Then there's a whole different set of "relations" for people ordering, like showing them past orders, which need to refer to the restaurant etc, and credit card transaction information for refunds etc. In your case, I can imagine a number of "relations" already, which suggest a more traditional SQL solution would work well: You have restaurants, they have maybe a few menus (regular, gluten-free etc), with menu items in, which have different prices over time (25% discount on christmas food just after christmas, 50% off pizzas on wednesdays).
The blog example shows up so much for DBMS like MongoDB, because it showcases what NoSQL / document storage is very scalable and performant in: mostly isolated documents with a few views / ways to order them and filter them. The main thing to consider around database choice, is what "shape" the data will be in, and the kind of read/write patterns you expect of that data. I can't speak for the NestJS vs ExpressJS discussion, but I can given a viewpoint on databases. I suspect that putting in a little bit more work up front will pay high dividends and productivity once the data is normalized.Īgain - it's largely a matter of preference but I prefer SQL almost every time.
I'm sure you can imagine what the data sets would look like if you use MongoDB or Postgres. It sounds like the type of problem you need to reverse engineer. I'm using Firestore with one of my apps and MongoDB with another app but they both use MySQL for the heavy lifting and then a document database for things like permissions, caching, etc. I'm much more experienced with MySQL than any other database and I am having a hard time getting on board with noSQL entirely because it's really hard to query complex data with relationships using noSQL.
#Atach to arangodb docker conainer update
You're going to have a really hard time normalizing the data when you can't manipulate relationships and bulk edit with a nice update query. I see that someone else responded and recommended MongoDB but since you are doing data analytics, I highly recommend you go with SQL. ArangoDB with 8.14K GitHub stars and 575 forks on GitHub appears to be more popular than PostgreSQL with 5.38K GitHub stars and 1.79K GitHub forks.Īccording to the StackShare community, PostgreSQL has a broader approval, being mentioned in 2701 company stacks & 2097 developers stacks compared to ArangoDB, which is listed in 11 company stacks and 13 developer stacks. "Grahps and documents in one DB" is the primary reason why developers consider ArangoDB over the competitors, whereas "Relational database" was stated as the key factor in picking PostgreSQL.ĪrangoDB and PostgreSQL are both open source tools. Transactions, foreign keys, subqueries, triggers, user-defined typesĪrangoDB and PostgreSQL can be categorized as "Databases" tools. That supports an extended subset of the SQL standard, including PostgreSQL is an advanced object-relational database management system Build high performance applications using a convenient SQL-like query language or JavaScript extensions PostgreSQL: A powerful, open source object-relational database system.
#Atach to arangodb docker conainer free
A distributed free and open-source database with a flexible data model for documents, graphs, and key-values. ArangoDB vs PostgreSQL: What are the differences?ĪrangoDB: A distributed open-source database with a flexible data model for documents, graphs, and key-values.
0 kommentar(er)
