381–390 of 419 posts
Mongo reminds me a wee bit of JS...
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.
Doing large incompatible migrations is unavoidable eventually, so avoiding them doesn't solve the problem either it just postpones the problem until the entire enterprise has to move to an entirely "new system" at fantastic cost. For some reason the old system never really dies so after the multimillion dollar migration the old zombie system still supports some business functions, leading to that replication anyway.…
Earlier quoted context omitted.
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.
Yes, and the way you solve it is by having an API that holds your business logic. That's how you avoid duplicating business logic in all those applications. Is your database just chock full of insane triggers and functions? Business logic doesn't belong in a database. data does.
Or you can rewrite all the third-party apps your organisation uses now and in the future to use your own.
Earlier quoted context omitted.
Can you give a use-case for such a constraint that can not be avoided by a better data organization? I'm not sure why you would deliberately design your data with constraints based on other row contents. Also: how do you enforce such constraints with MongoDB exactly? If the answer is "do it in the application", then your answer applies to relational databases too.
A common example is making sure that every event in a bookkeeping system balances to zero (e.g. three rows: -125 EUR bank, +100 EUR office materials, +25 EUR tax). To enforce this at the database level you either need to run at SERIALIZABLE, take a table lock, or do something horrible with your database structure (like putting all rows of the event in a JSON blob). When I have solved this case I have done it in the a…
Earlier quoted context omitted.
Doing large incompatible migrations is unavoidable eventually, so avoiding them doesn't solve the problem either it just postpones the problem until the entire enterprise has to move to an entirely "new system" at fantastic cost. For some reason the old system never really dies so after the multimillion dollar migration the old zombie system still supports some business functions, leading to that replication anyway.…
Its not unchangeable. That's the point. You can easily add things without needing to do a "SQL migration".
In the end it means you give the data an elevated role in the system, and you write the code around the data. When the code would be cheaper to write or maintain with a different data representation - you can't. It's a comfortable situation for a while, but when you eventually grow out of the current system it's a world of hurt.
Like I said - it's two bad (non) solutions but I very much prefer duplication, isolation, inconsistency, a forest of small obscure APIs etc. where I can add/remove/normalize/denormalize/add caching etc - to "the data is the ground truth and the schema we can only change through addition" non-solution.
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…
I wouldn't call a JIRA ticket good documentation. While I agree that it's good to know the limitations of the tools you chose those limitations should be clearly spelled out in the documentation. I don't think most programmers have the luxury of learning all the voodoo and lore that surrounds MongoDB from JIRA tickets and blog posts.
That's how I learned everything I know about most FOSS products I have encountered - through the code pages and social media surrounding the project.
Pretty much everything about the mongodb hate derives from their marketing and sales. The truth is, they've obviously stumbled onto something the market wants, otherwise they would never have become so successful.
For me, as a long-time programmer with no database experience, the mental mapping of JSON constructs as both data and query language was far easier for me to absorb than the relational model, which didn't fit the paradigms that I was used to.
At my present gig, we've used Mongo DB for two years, scaling up to quite a large production setup. Like any technology it has strengths and weaknesses, but it has not been the utter failure that readers of Hacker News would be led to expect. We adopted it knowing quite a bit about its history, and it has turned out to be an excellent choice that has held up over time.
Periodically we've considered switching to postgres, and we may do so for part of our stack. But for the core jobs of data collection and batch processing data with fluid schema, I'm pretty sure we will stick with mongodb for the duration.
It's just a tool, folks.
Earlier quoted context omitted.
Its not unchangeable. That's the point. You can easily add things without needing to do a "SQL migration".
Yes. But "adding" is a pretty small subset of changes. If you need to do even a trivial migration like the classic "merge first and last name columns into a single column" is pretty hairy if you have a dozen legacy apps that assume "customers" have "firstname". In the end it means you give the data an elevated role in the system, and you write the code around the data. When the code would be cheaper to write or maint…
That's how things are meant to be. The structure of a program naturally follows that of the data it manipulates.
> When the code would be cheaper to write or maintain with a different data representation - you can't.
Who says that? The real problem is that most programming languages aren't capable of integrating database schemas into the type-checking process, so when you change a schema, it's difficult to make sure applications follow through in a consistent manner. That's what makes change unnecessarily risky and painful. But it's possible to do better than that: http://impredicative.com/ur/
This is exactly what I thought. You are a DBA. You are not a programmer. Whenever I read these threads I think "either these people are all DBAs or they have an extreme emotional attachment to a particular database". There it is - this is a thread full of DBAs rebelling against a database that takes away their power and responsibility.
Also, please don't create many obscure throwaway accounts on HN. This forum is a community. Anonymity is fine, but users should have some consistent identity that other users can relate to. Otherwise we may as well have no usernames and no community at all, and that would be an entirely different forum.
We detached this subthread from https://news.ycombinator.com/item?id=11860186 and marked it off-topic.
> 1) Have migrations (except they're going to be some scary ad hoc nodejs script that loop through your document store and modify fields on the fly). Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql. What is even worse is that, despite nobody here acknowledging it, must SQL databases are used with an ORM. Now in your migration script you have to hac…
We detached this subthread from https://news.ycombinator.com/item?id=11859027 and marked it off-topic.