241–250 of 339 posts
This seems to gloss over the actual rewrite. How did you ensure queries were equivalent? How did you configure the product to be able to read from and write to both databases? Did migrating reveal any bugs? Were you largely able to port your queries 1:1?
Then checking which query doesn't return the same result set.
It was super shitty when it came out and using postgres gives you a better and faster solution which you can also use in other projects.
I'm always impressed when I see mongodb still making money.
I use MySQL for everything - always have. Can someone hit me with a few reasons why you would use Postgres over MySQL? I don’t have any familial affinity to any database, but I’m not sure what the benefits to Postgres are relative to MySQL.
Umm... why would you not choose a relational engine to start with? This isn't said with the benefit of hindsight. I worked with Lotus 123 back in the early 90s. I get that there's value in document databases, but even then, there were limitations, and the need for the ability to have structured/related data in an engine that easily allowed for ad-hoc queries out of the box was apparent.
I watched the entire nosql/mongo movement arise and evolve over time, and it rarely made sense to me. Even when mongo made sense for a problem... it only makes sense for that problem, and not as the primary basis for your entire application. Relational/SQL, with nosql/mongo/etc as secondary/ancillary data store has always made the most sense (imo).
JSON columns in major databases now tend to provide a pragmatic balance of "good balance for many use cases". Justifying something other than that as a starting point is possible, but I've rarely seen cases where it makes sense to avoid a decent SQL engine as the core data store for your business apps.
Earlier quoted context omitted.
I recall when my team chose MongoDB ~2011, Postgres & friends didn't have JSON columns, so there was a lot of extra data modelling that probably was unnecessary. The biggest use case for MongoDB was for huMongous data. Obvs MongoDB was a good fit, because of the name.
I still didn't have a single use-case to use JSON columns yet. Sometimes I feel that JSON columns are made for people who don't want to properly design their domain model. Big mistake.
(Mind I mean the discussion is misguided, not you)
The problem is that relational model is a one solution to certain problem of when you want to pay the price of enforcing the model of your data. Relational database is when you pay all the cost upfront.
With MongoDB I have other options.
It does not mean they are necessarily better options. But some of them are better in some situations, for example when rapid prototyping. Or when you need to preserve data in different formats as the application evolves.
Personally, if you can, you probably should model your data upfront. But it is good to have other options, sometimes.
Although in this case, the authors originally chose an architecture that was poorly suited to their data model. They had relational data and put it in a non-relational store. This was obviously always going to cause problems.
I remember well how in the early 2000s everybody wanted to get away from their relational systems and NoSQL (Not only SQL) databases were the latest fashion. Looks like we have come full cycle.
Relational databases have also evolved. With JSON types you can now easily mix relations and documents.
Ah, the old "I used a wrong product for my problem and now I complain the product is bad because it does not suit my case." defence. MongoDB is a document database. It is not supposed to be good at relations. Also lacking support with cloud providers and lacking experience with MongoDB is not MongoDB's problem, it is your poor decisionmaking. If you value those things, you should have taken it into account when you w…
>As part of that stack, we chose MongoDB + Mongoose ORM because the combination presented least overhead and allowed us to ship quality features quickly. As Sir Tony Hoare states, “premature optimization is the root of all evil,” and there was certainly no need for further optimization at the time. Looks like the tool did a great job while they were getting started. Mongo is very easy to hack something together with,…
The one unsolicited piece of tech advice I always give is “Just use Postgres”. Postgres Is Enough: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... There’s some Mongo/json alternatives in the list if you really need unstructured data. And there’s a huge plug-in ecosystem as well for just about anything you could imagine.
But isn't there a point before which "just use sqlite" is more appropriate advice?
If you need a networked database supporting many users, probably better off with Postgres.
Earlier quoted context omitted.
Building an mvp or a single container app. I’m actually trying to get Postgres to work like this right now. SQLite being embedded is simpler to use and more performant in this environment as there is no IPC overhead.
Why even use a database? Just assign a variable. All state is dead the second you destroy the container anyways.