371–380 of 419 posts
Earlier quoted context omitted.
NodeJS + MongoDB is this generation's Laurel and Hardy stack ("look at this mess you got me into"). Last generation's was PHP + MySQL.
Actually PHP and MySQL is a pretty respectable stack today if you use it right.
Earlier quoted context omitted.
I really want an excuse to build something with CouchDB and PouchDB ( https://pouchdb.com/ ). Can you expand on your experiences with it?
I'm not the original poster, but I can give you some of my limited experience with CouchDB from an application I inherited. The original idea for the project still seems like a good idea to me. Basically they wanted to record events that came into the system and store them in a write only ledger. Then they wanted to version every change so that you have an audit trail. Finally they wanted to be able to create views o…
one of the things I want to try (but have only done some
preliminary trials with) is to keep the concept of the
write only ledger, but to replicate the db into several
views of the data (some with severely restricted content).
Earlier quoted context omitted.
> Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" f…
> I've written a ton of SQL migrations this year, none of them are scary or even really count as "big bunch of sql". If this describes your code, you should probably stop and rethink what you're doing, because that's bad practice. The difference between, eg, merging your "first_name" and "last_name" fields into a single "name" field with Mongo or a SQL DB is basically that the SQL DB has better tooling so it'll be cl…
Your other comments already make you sound like a petulant child and a moron (or at the very least, someone with no actual real-world experience), but this just the cherry on the cake.
SQL is extremely powerful, and using it effectively doesn't take much more effort than learning another new mainstream programming language.
Anyway, enjoy your tortured use of shitty ORMs + Mongo for your toy projects; move aside and let the real programmers go on with their work.
Earlier quoted context omitted.
As a guy who works on ACID database internals, I'm appalled that people use MongoDB. You want a document store? Use Postgres. Why on earth would you use a database that makes so little in the way of guarantees about what results you get from it? I think most people have really low load and concurrency, so things seem to work. When things get busier you're in for a world of pain. Look I get that's it's easy to use and…
Here's one: You're dealing with a torrent of incoming semi-unstructured data, where losing a good chunk of it is minor nuisance because you only need a decent sample, from which you extract data. In those kind of scenarios, making it easy to work on the code can often be far more important than reliability. I have a project like that now. I'd love to use Postgres, and probably will eventually once things "settle down…
Earlier quoted context omitted.
You're replies in the comments are rude and borderline fanatical in tone. There are two classes of constraints: one being 'this string shouldn't be longer/shorter than x' or 'this value should only be between 1 and 10'. The other kind is 'on the first Tuesday of every month only during a full moon can this record be deleted, and only by a user with permission X'. The first can easily be modelled in SQL, the second sh…
This is just a semantics argument which is boring. A number between 1 and 10 on Tuesday is only slightly different. You can say it is not arbitrary, whatever. You have just proved my point. Just in case you forgot the original claim, it was that if you use a SQL database, the constraints are in your database, but if you use mongo, the constraints are in your code. I refuted this by saying that the constraints are als…
It's not arbitrary, because the constraints at least in Postgres are themselves constrained to validating a single row in a single table. Your app code can be truly arbitrary, you could trigger a device that posts a carrier pigeon to someone many miles away and waits for it to return with a result. That's arbitrary.
> Just in case you forgot the original claim, it was that if you use a SQL database, the constraints are in your database, but if you use mongo, the constraints are in your code.
Sorry, that's not what I was claiming. I was stating, correctly, that constraints relating to the data belong in the database. Constraints belonging to the business logic that powers your app belong in your app. You can be 100% sure that a constraint in your database will be respected, whereas the same can't be said of your apps code.
If you are given a specification that says "no username can be longer than 12 characters", that's what you add to your database constraints. A specification that says "No emails from temporary email providers are allowed" belong in your app code. Clear separation of concerns, that mongodb has no clue about. 'Just validate everything in your code, and if you get junk data in your database then I fucking hope your code can handle it'. Please.
> Therefore, saying that it is a great win that a SQL database can do some basic constraints checking
It can do pretty complex constraints. On the data. The more complex, completely arbitrary constraints belong in your app code.
> is a ridiculous argument because it hardly contributes any benefit due to the fact that even more complex constraints are in the code.
What. That makes no sense. So having 100% certainty that no column value in your database will violate any of the constraints you place on it 'hardly contributes any benefits' because... you have other, unrelated, business constraints in your app? What logic is this?
Oh, the fud of it. The behavior is well documented here https://jira.mongodb.org/browse/SERVER-14766 and in the linked issues. Seasoned users of mongodb know to structure their queries to avoid depending on a cursor if the collection may be concurrently updated by another process. The usual pattern is to re-query the db in cases where your cursor may have gone stale. This tends to be habit due to the 10-minute cursor…
Yes, with enough extremely careful coding knowing exactly all the internals of the database, you can probably avoid these giant gotchas. But that's a hell of a lot of work for a DB that's supposed to be easy.
And then you're still dealing with a database without ACID guarantees. No transactions, very little atomicity.... and good luck if your server crashes... we've had multiple customers have their DB corrupted that way.
MongoDB is only good for storing data you don't really care about... in which case, why are you bothering to store it at all?
What most people end up storing in Mongo: strongly schema'ed, relational data that is critical to their application. This is exactly what mongo is not for.
Earlier quoted context omitted.
They are not "each others" databases tho'. It is "the database", deliberately chosen as the integration point. The alternative is a horrific tangle of replication, or a vast undiscoverable landscape of tiny APIs.
That sounds horrible. No wonder you've never done a migration - it's been made impossible. Why would you not hide the database behind an API, so that you CAN migrate it, change it, etc? This is like not having a separate data layer in your application, except it's across many applications all at once.
These are solved problems, have been for decades.
Earlier quoted context omitted.
That sounds horrible. No wonder you've never done a migration - it's been made impossible. Why would you not hide the database behind an API, so that you CAN migrate it, change it, etc? This is like not having a separate data layer in your application, except it's across many applications all at once.
What API do you suggest? Bear in mind it needs to provide the same results and enforce the same constraints for everything from COBOL to Java to Excel to ColdFusion to Python to R and any other future language. I mean you could write your business logic in all of them, and maintain it in all of them, but that would be insane. These are solved problems, have been for decades.
Business logic doesn't belong in a database. data does.
Earlier quoted context omitted.
> You can only normalize a relational schema. Normalization is just a method of organization to minimize repetition of data. It has nothing to do with efficiency of operation. This is perfectly valid code: person = { _id: "person123", username: "lloyd-christmas" } comment = { _id: "comment123", person: "person123", text: "This is how I start", } You don't have to do: person = { _id: "person123", username: "lloyd-chri…
You can normalize data in Mongo and replicate relational database features in your application layer. I'm just curious how that's an upside to using a relational database from the beginning when your plan is to migrate to a relational database anyways. Switch out "Mongo" for "Postgres" in your bulk paragraph and you have the same scenario but with less work on your part and more features to help establish your data m…
The bottom level of our application layer is a query builder which is almost a drag and drop replacement between mongo and postgres. By the time that layer is built out, we know what our database needs to look like. I find that adding/dropping fields and models in mongo to be drastically faster than moving models around in postgres. The above example would obviously end up in the same structure, whether we started with relational or not. It was nothing more than demonstrating an iterative process where you don't need to START denormalized just because "that's why you use nosql".
We try to be as incremental as possible when building our apps, and have found that using nosql allows for 20 small refactors that often end up being 2 larger refactors with a relational db. We've just found that it ends up being a faster production process, and we end up with a much more application-specific database instead of just "This is a Person, this is an Address, this is a Comment". Sure, we know beforehand that the application will contain all those components. We don't necessarily know how they'll be used in a request-by-request basis, and whether or not they will actually end up being one-to-one, one-to-many, or many-to-many.
Earlier quoted context omitted.
I'd argue the inverse. Serious organisations shouldn't have lots of different apps reading from each other's databases, for the reason you suggest above. It makes changes difficult and the application landscape fragile. It also encourages not having well-documented interdependencies between your apps (and consequently no way of knowing what the impact of any given change to an app will have). It's not uncommon howeve…
They are not "each others" databases tho'. It is "the database", deliberately chosen as the integration point. The alternative is a horrific tangle of replication, or a vast undiscoverable landscape of tiny APIs.
Both solutions are unpalatable: "the database is the integration point we can't ever change" is bad and "no apps have a central ground truth database" is also painful.
I'd prefer the latter with small APIs and more duplication, than the common enterprise solution with a massive holy unchangable db directly serving apps.