7 ms·

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, i

by cmenge 9y ago

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginners believe that SQL databases guarantee serializability everywhere and all the time, relying on the database (and OR-mappers) a lot / too much in my opinion. Choosing a system that only offers very few guarantees forces you to think about them more explicitly. On the other hand, if you never bothered to understand SQL, you probably won't bother understanding anyDB's restrictions and guarantees either, and then everything goes to sh*t. Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV.

danpalmer 9y ago
> Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV. I agree with most of this, relational databases have a lot of moving parts that many developers (myself included) don't fully understand. However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive.
- adjkant 9y ago
  +1 - Mongo is much easier to misuse. Not to mention that many users of SQL these days use ORM's that abstract many of the complex SQL features with a professional library that actually knows how to handle the small details and only exposes a basic subset of functionality that is good enough for most use cases.
- Bartweiss 9y ago
  > I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. Strongly, strongly agreed. Learning every moving part in InnoDB (as an example) is quite a task. But not knowing about those features will rarely burn you, and it's usually apparent when you need to know something you don't. Meanwhile Mongo... well, Mongo says a replicated write is complete as soon as it's queued to be written. They eventually updated the default settings to be slightly less catastrophic, but still far from good. What you don't know about Mongo can and will hurt you, which arguably makes the appearance of ease a drawback. http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/
  - tinix 9y ago
    Man, people just looooove to link 5 year old blogs about fault tolerance, meanwhile that isn't even relevant anymore, and honestly, it wasn't relevant at the time either, because changing the write concern is trivial. The real nugget of truth here is this; don't use tools that you don't understand... PERIOD. Further, there are a plethora of alternative engines for Mongo that do have fault tolerance in mind.
- kazen44 9y ago
  > However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive. Postgres has good and sane defaults. Also the documentation INSIDE the config file is top notch. The one thing which makes postgres the golden standard in my opinion is its extensive documentation. Documentation is key to maintaining an RDBMS Mysql does some weird things on an initial install, and documentation is sadly all over the place.
winter_blue 9y ago
Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore. 2. Relations: Foreign keys are incredibly useful. They're the biggest feature I miss out in relational databases. They help keep your data in a sane state. If a user deletes his account, you can configure your database use a DELETE CASCADE to automatically remove all data associated with the user. 3. Normalization: NoSQL databases encourage you to denormalize your data. I've seen NoSQL databses frequently run into problems with stale data, with date that is duplicated and not kept updated, where you have multiple out-of-sync version of the same piece of information. With NoSQL database, you have to handle all the complications of denormalization. (You, the developer, have to remember to update/delete/etc from the multiple places the same piece of data lives in.) The database doesn't do it for you. (The database is a dumb key-value store, nothing more.) Relational databases encourage keeping the logical design of your databse normalized. To quote Wikipedia: "The preferred method is to keep the logical design normalised, but allow the database management system (DBMS) to store additional redundant information on disk to optimise query response. In this case it is the DBMS software's responsibility to ensure that any redundant copies are kept consistent. This method is often implemented in SQL as indexed views (Microsoft SQL Server) or materialised views (Oracle).". 4. Schemas: The worst thing about NoSQL is the absence of an enforced schema. Schemaless databases are a scourge. There's always a schema -- it's just that it's scattered all over the code. If you are joining a new company, you have to sift through piles of code to figure what the structure of the data is. Schemas are like types, and my dislike for dynamically typed languages carries over to schema-less database. Relational databases make you think carefully about the schema, and specify the schema explicitly. In the end, you end up needing to do a lot of extra work, likely end up with more unstable and buggy system, just to avoid the small amount of totally-worth-it upfront work that setting up a relational database requires.
- flavio81 9y ago
  > There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. I am a happy user and can recommend the following ORMs: for Java, Hibernate (a classic) for C# in .NET, how about... NHibernate? for Python... SQLAlchemy. Really good software. WARNING: they require you to read the manual.
flavio81 9y ago
> Choosing a system that only offers very few guarantees forces you to think about them more explicitly. Yes, of course. And it also forces you to implement, on your own: relational (key) constraints, real transactions, etc. And thus, you, on your own, compete against more or less 44 years of research, developing, and releases by brilliant computer scientists and engineers (Ingres DB, 1973- PostgreSQL latest version, 2017), scientists who already solved those problems {relational constraints, transactions, etc} and made said solutions perform to the max possible. So a better alternative is to simply... learn more about relational databases.
- cmenge 9y ago
  I'm sorry, you're so right. I'm just one of the idiots on the Internet who haven't used a system for 10+ years (or the bulk of their existence at least) and makes condescending comments...
topspin 9y ago
"some text-based SQL statements" What do you have in mind there? Systems that process SQL statements interpret these statements, validate them for correctness against a schema and then provide an auditable plan. Just because SQL bears some resemblance to spoken/written English (a property that vanishes pretty quick when you get past simple use cases) doesn't mean it isn't rigorously analyzed by database systems; SELECT isn't some alternative form of 'grep.' Perhaps you're thinking of SQL injection attacks that plague that the LAMP stack? If so then you should know that NoSQL isn't immune to injection attacks. Here[1] is an OWASP page on testing for NoSQL injection vulnerabilities; the same sloppy coding patterns that allow attackers to synthesize SQL statements are also manifest in NoSQL applications. [1] https://www.owasp.org/index.php/Testing_for_NoSQL_injection https://www.owasp.org/index.php/Testing_for_NoSQL_injection
- cmenge 9y ago
  Being condescending isn't helping your argument here. No, I didn't think of SQL injection and I do have a vague understanding of the SQL grammar. The NoSQL injections seem a bit constructed and pretty much can't happen with a strongly typed language in the application layer.

by cmenge 9y ago

danpalmer 9y ago

> Some databases might be easier to understand than others, but I feel MongoDB is on the 'easier' end here. YMMV. I agree with most of this, relational databases have a lot of moving parts that many developers (myself included) don't fully understand. However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive.

adjkant 9y ago
+1 - Mongo is much easier to misuse. Not to mention that many users of SQL these days use ORM's that abstract many of the complex SQL features with a professional library that actually knows how to handle the small details and only exposes a basic subset of functionality that is good enough for most use cases.
Bartweiss 9y ago
> I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. Strongly, strongly agreed. Learning every moving part in InnoDB (as an example) is quite a task. But not knowing about those features will rarely burn you, and it's usually apparent when you need to know something you don't. Meanwhile Mongo... well, Mongo says a replicated write is complete as soon as it's queued to be written. They eventually updated the default settings to be slightly less catastrophic, but still far from good. What you don't know about Mongo can and will hurt you, which arguably makes the appearance of ease a drawback. http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/
- tinix 9y ago
  Man, people just looooove to link 5 year old blogs about fault tolerance, meanwhile that isn't even relevant anymore, and honestly, it wasn't relevant at the time either, because changing the write concern is trivial. The real nugget of truth here is this; don't use tools that you don't understand... PERIOD. Further, there are a plethora of alternative engines for Mongo that do have fault tolerance in mind.
kazen44 9y ago
> However, I believe relational databases (Postgres is what I have experience with) has defaults that are basically correct, and unlikely to cause significant issues, whereas in my experience MongoDB did not have this. MongoDB might be easier to understand on the surface, but I think that's deceptive. Postgres has good and sane defaults. Also the documentation INSIDE the config file is top notch. The one thing which makes postgres the golden standard in my opinion is its extensive documentation. Documentation is key to maintaining an RDBMS Mysql does some weird things on an initial install, and documentation is sadly all over the place.

winter_blue 9y ago

Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore. 2. Relations: Foreign keys are incredibly useful. They're the biggest feature I miss out in relational databases. They help keep your data in a sane state. If a user deletes his account, you can configure your database use a DELETE CASCADE to automatically remove all data associated with the user. 3. Normalization: NoSQL databases encourage you to denormalize your data. I've seen NoSQL databses frequently run into problems with stale data, with date that is duplicated and not kept updated, where you have multiple out-of-sync version of the same piece of information. With NoSQL database, you have to handle all the complications of denormalization. (You, the developer, have to remember to update/delete/etc from the multiple places the same piece of data lives in.) The database doesn't do it for you. (The database is a dumb key-value store, nothing more.) Relational databases encourage keeping the logical design of your databse normalized. To quote Wikipedia: "The preferred method is to keep the logical design normalised, but allow the database management system (DBMS) to store additional redundant information on disk to optimise query response. In this case it is the DBMS software's responsibility to ensure that any redundant copies are kept consistent. This method is often implemented in SQL as indexed views (Microsoft SQL Server) or materialised views (Oracle).". 4. Schemas: The worst thing about NoSQL is the absence of an enforced schema. Schemaless databases are a scourge. There's always a schema -- it's just that it's scattered all over the code. If you are joining a new company, you have to sift through piles of code to figure what the structure of the data is. Schemas are like types, and my dislike for dynamically typed languages carries over to schema-less database. Relational databases make you think carefully about the schema, and specify the schema explicitly. In the end, you end up needing to do a lot of extra work, likely end up with more unstable and buggy system, just to avoid the small amount of totally-worth-it upfront work that setting up a relational database requires.

flavio81 9y ago
> There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. I am a happy user and can recommend the following ORMs: for Java, Hibernate (a classic) for C# in .NET, how about... NHibernate? for Python... SQLAlchemy. Really good software. WARNING: they require you to read the manual.

flavio81 9y ago

> Choosing a system that only offers very few guarantees forces you to think about them more explicitly. Yes, of course. And it also forces you to implement, on your own: relational (key) constraints, real transactions, etc. And thus, you, on your own, compete against more or less 44 years of research, developing, and releases by brilliant computer scientists and engineers (Ingres DB, 1973- PostgreSQL latest version, 2017), scientists who already solved those problems {relational constraints, transactions, etc} and made said solutions perform to the max possible. So a better alternative is to simply... learn more about relational databases.

cmenge 9y ago
I'm sorry, you're so right. I'm just one of the idiots on the Internet who haven't used a system for 10+ years (or the bulk of their existence at least) and makes condescending comments...

topspin 9y ago

"some text-based SQL statements" What do you have in mind there? Systems that process SQL statements interpret these statements, validate them for correctness against a schema and then provide an auditable plan. Just because SQL bears some resemblance to spoken/written English (a property that vanishes pretty quick when you get past simple use cases) doesn't mean it isn't rigorously analyzed by database systems; SELECT isn't some alternative form of 'grep.' Perhaps you're thinking of SQL injection attacks that plague that the LAMP stack? If so then you should know that NoSQL isn't immune to injection attacks. Here[1] is an OWASP page on testing for NoSQL injection vulnerabilities; the same sloppy coding patterns that allow attackers to synthesize SQL statements are also manifest in NoSQL applications. [1] https://www.owasp.org/index.php/Testing_for_NoSQL_injection https://www.owasp.org/index.php/Testing_for_NoSQL_injection

cmenge 9y ago
Being condescending isn't helping your argument here. No, I didn't think of SQL injection and I do have a vague understanding of the SQL grammar. The NoSQL injections seem a bit constructed and pretty much can't happen with a strongly typed language in the application layer.