12 ms·

like the yesterday's submission of "Why you should never use MongoDB (2013)" (https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id

by ta0967 10y ago

like the yesterday's submission of "Why you should never use MongoDB (2013)" (https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id=12290739), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study history of their field and, as a result, don't even recognize they're repeating 50 years old mistakes. sure, SQL has fallen so short of the promise of the relational model it's not even funny, but don't conflate the model with the query language, folks!

velocitypsycho 10y ago
Right tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.
- ta0967 10y ago
  but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model. if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single pre-designated root. both relational and hierarchical databases let you go from department to employee, only one lets you go from employee to their department without enumeration. what purpose does precluding the latter serve?
  - electricEmu 10y ago
    Speed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.
    - steego 10y ago
      > Speed of development and execution when I don't, and will likely never need, to query that way. The initial joy and speed of of development is really nice. However, my experience has been you end up paying significant technical debt when the specs evolve faster than you think.
      - electricEmu 10y ago
        I agree,and migrations can be a ghetto. With that known, I do side step constant SQL migrations and even get to skip simple migrations all together by specifying defaults in my domain.
    - ta0967 10y ago
      you ignored the silver bullet criticism i don't think so, i simply refuse to have my arguments framed that way since i'm very well aware of the shortcomings present in what has so far passed for a "RDBMS". i consider velocitypsycho's argument ("Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet.") a non-sequitur: the former is a proper superset of the latter, that sentence simply "does not compute". doubled down on SQL as the silver bullet where does the post you replied to mention SQL? are you confusing SQL for the relational model?
      - gaius 10y ago
        It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".
        redrummr 10y ago
        But let's not forget that schema-less databases are often marketed as noSQL, so typing sql (quicker on phone) should be acceptable imo.
        bunderbunder 10y ago
pjmlp 10y ago
I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.
- api 10y ago
  NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only.
  - catnaroek 10y ago
    > Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. The CAP theorem doesn't force you to give up consistency within a single node. NoSQL databases often do, though. > All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only. So, instead of fixing programming languages, let's cripple databases?
    - api 10y ago
      I meant to suggest instead that we fix languages, and now that I think of it .net's linq is not bad.
      - catnaroek 10y ago
        LINQ makes querying somewhat more pleasant, but it doesn't fix the real problem: relations are inexpressible as first-class values (not the same thing as first-class objects!) in most object-oriented languages.
  - 10y ago
catnaroek 10y ago
The relational model does have deficiencies, but the right way to address them is with more powerful schemas, not less. See: “categorical databases”. (Think about it this way: SQL is Java. NoSQL is your typical extremely forgiving dynamic language. We need a database equivalent of ML and Haskell.) NoSQL is simply the result of not wanting to think about the logical structure of data. Plain intellectual laziness.
- pjmlp 10y ago
  And the millennials dislike for not wanting to learn SQL, I think. You always see how they bash having to learn SQL on those presentations.
- jimbokun 10y ago
  "NoSQL is simply the result of not wanting to think about the logical structure of data." NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. Key value stores scale great, at the cost of having almost no query capabilities to speak of. Now, some developers may adopt NoSQL due to the ease of getting a new project started. But I don't think that was the main motivation of the developers of the major NoSQL databases. (Although, NoSQL is so broad I'm sure there are counter examples.)
  - catnaroek 10y ago
    > NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. You can give up global consistency without sacrificing local (single-node) consistency. And normalization isn't an all-or-nothing proposition: you can select the kind of schema that best fits your needs. Unlike the case with NoSQL, which just says “lalala... I can't hear you” whenever you bring up consistency. > Key value stores scale great, at the cost of having almost no query capabilities to speak of. Far more worrisome is the loss of data integrity guarantees. It's okay to let me selectively disable these guarantees when I don't need them (say, by using a less structured schema), but a “database management system” that doesn't let me enforce the intended structure of my data, under any configuration, is simply not worthy of the name “database management system”.
candu 10y ago
^ this. To be fair, though, it is genuinely difficult to gauge which technologies are worth adopting. Clearly some are, otherwise we'd all still be writing hand-crafted assembler to optimize drum memory I/O, or perhaps heaps of Perl CGI scripts. It's also unrealistic to expect the average programmer - hell, even the pretty good programmer - to be aware of 50+ years of relevant research. For starters, many of them can't even access the relevant papers without paying some gatekeeper a whole lot for the privilege. If they could, they'd need a significant investment of time to understand them, especially without ready access to domain experts who can tell them which papers are most worth reading and in which order. (All of these are benefits of graduate student life that are often taken for granted.)
- catnaroek 10y ago
  Intuitively understanding the benefits of the relational model doesn't require access to scientific publications. Just a little bit of mathematical inclination and, most importantly, basic common sense.
zinssmeister 10y ago
what does PFYs stand for?
- ta0967 10y ago
  Pimply-Faced Youth :)
  - jharger 10y ago
    The PFYs need to read some BOFH. :)
JustUhThought 10y ago
Amen, brother!!!
mpweiher 10y ago
Greybeard here. I suggest you check out The End of an Architectural Era (It’s Time for a Complete Rewrite)[1]. The "failure" of non-relational databases was for specific application domains. [1] http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf
dpacmittal 10y ago
Then why are we only singling out Mongo. Doesn't this also apply to other NoSQL stores.
- galdosdi 10y ago
  Mongo isn't the only bad one but it's kind of humorously become the canononical bad one -- where by "bad one" I mean the kind of NoSQL database you choose just because you don't understand SQL) and not because you have a specific scaling need. A good example of a NoSQL database you'd pick to help with write scaling might be Cassandra (which has schemas and is looking more and more SQL like these days with CQL -- the consistency and data models are just different to allow for writes to scale up) Not saying Mongo doesn't have any legitimate uses (although I honestly suspect it doesn't, not even the ones listed at the end of TFA, at least not assuming the developer is already well versed in using a good relational database and related tooling. In fact I think I'd be willing to challenge and bet money against a mongo proponent to see who could create "an MVP on a super-tight schedule" faster.)

by ta0967 10y ago

velocitypsycho 10y ago

Right tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.

ta0967 10y ago
but we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model. if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single pre-designated root. both relational and hierarchical databases let you go from department to employee, only one lets you go from employee to their department without enumeration. what purpose does precluding the latter serve?
- electricEmu 10y ago
  Speed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.
  - steego 10y ago
    > Speed of development and execution when I don't, and will likely never need, to query that way. The initial joy and speed of of development is really nice. However, my experience has been you end up paying significant technical debt when the specs evolve faster than you think.
    - electricEmu 10y ago
      I agree,and migrations can be a ghetto. With that known, I do side step constant SQL migrations and even get to skip simple migrations all together by specifying defaults in my domain.
  - ta0967 10y ago
    you ignored the silver bullet criticism i don't think so, i simply refuse to have my arguments framed that way since i'm very well aware of the shortcomings present in what has so far passed for a "RDBMS". i consider velocitypsycho's argument ("Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet.") a non-sequitur: the former is a proper superset of the latter, that sentence simply "does not compute". doubled down on SQL as the silver bullet where does the post you replied to mention SQL? are you confusing SQL for the relational model?
    - gaius 10y ago
      It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".
      - redrummr 10y ago
        But let's not forget that schema-less databases are often marketed as noSQL, so typing sql (quicker on phone) should be acceptable imo.
        bunderbunder 10y ago

pjmlp 10y ago

I am yet to fail into this NoSQL trend. Yes, SQL does have its issues, but I am yet to work on any project where the relational data model doesn't fit. Plus all the stuff that we can do at the SQL engine level, specially data validation, is just great for the type of stuff we develop.

api 10y ago
NoSQL is driven more by scaling issues than anything else. Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. There is also the fact that no programming language lets you deal with relational data sanely in code, so you have the well known impedance mismatch heaeache. All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only.
- catnaroek 10y ago
  > Joins and strong consistency are awesome but run head first into the CAP theorem and other concerns like single node performance on a sharded cluster. The CAP theorem doesn't force you to give up consistency within a single node. NoSQL databases often do, though. > All popular languages I've seen offer hierarchical (maps of maps etc.) and more primitive structures only. So, instead of fixing programming languages, let's cripple databases?
  - api 10y ago
    I meant to suggest instead that we fix languages, and now that I think of it .net's linq is not bad.
    - catnaroek 10y ago
      LINQ makes querying somewhat more pleasant, but it doesn't fix the real problem: relations are inexpressible as first-class values (not the same thing as first-class objects!) in most object-oriented languages.
- 10y ago

catnaroek 10y ago

The relational model does have deficiencies, but the right way to address them is with more powerful schemas, not less. See: “categorical databases”. (Think about it this way: SQL is Java. NoSQL is your typical extremely forgiving dynamic language. We need a database equivalent of ML and Haskell.) NoSQL is simply the result of not wanting to think about the logical structure of data. Plain intellectual laziness.

pjmlp 10y ago
And the millennials dislike for not wanting to learn SQL, I think. You always see how they bash having to learn SQL on those presentations.
jimbokun 10y ago
"NoSQL is simply the result of not wanting to think about the logical structure of data." NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. Key value stores scale great, at the cost of having almost no query capabilities to speak of. Now, some developers may adopt NoSQL due to the ease of getting a new project started. But I don't think that was the main motivation of the developers of the major NoSQL databases. (Although, NoSQL is so broad I'm sure there are counter examples.)
- catnaroek 10y ago
  > NoSQL was an attempt to scale by sacrificing some of the capabilities of the relational model. You can give up global consistency without sacrificing local (single-node) consistency. And normalization isn't an all-or-nothing proposition: you can select the kind of schema that best fits your needs. Unlike the case with NoSQL, which just says “lalala... I can't hear you” whenever you bring up consistency. > Key value stores scale great, at the cost of having almost no query capabilities to speak of. Far more worrisome is the loss of data integrity guarantees. It's okay to let me selectively disable these guarantees when I don't need them (say, by using a less structured schema), but a “database management system” that doesn't let me enforce the intended structure of my data, under any configuration, is simply not worthy of the name “database management system”.

candu 10y ago

^ this. To be fair, though, it is genuinely difficult to gauge which technologies are worth adopting. Clearly some are, otherwise we'd all still be writing hand-crafted assembler to optimize drum memory I/O, or perhaps heaps of Perl CGI scripts. It's also unrealistic to expect the average programmer - hell, even the pretty good programmer - to be aware of 50+ years of relevant research. For starters, many of them can't even access the relevant papers without paying some gatekeeper a whole lot for the privilege. If they could, they'd need a significant investment of time to understand them, especially without ready access to domain experts who can tell them which papers are most worth reading and in which order. (All of these are benefits of graduate student life that are often taken for granted.)

catnaroek 10y ago
Intuitively understanding the benefits of the relational model doesn't require access to scientific publications. Just a little bit of mathematical inclination and, most importantly, basic common sense.

zinssmeister 10y ago

what does PFYs stand for?

ta0967 10y ago
Pimply-Faced Youth :)
- jharger 10y ago
  The PFYs need to read some BOFH. :)

JustUhThought 10y ago

Amen, brother!!!

mpweiher 10y ago

Greybeard here. I suggest you check out The End of an Architectural Era (It’s Time for a Complete Rewrite)[1]. The "failure" of non-relational databases was for specific application domains. [1] http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf

dpacmittal 10y ago

Then why are we only singling out Mongo. Doesn't this also apply to other NoSQL stores.

galdosdi 10y ago
Mongo isn't the only bad one but it's kind of humorously become the canononical bad one -- where by "bad one" I mean the kind of NoSQL database you choose just because you don't understand SQL) and not because you have a specific scaling need. A good example of a NoSQL database you'd pick to help with write scaling might be Cassandra (which has schemas and is looking more and more SQL like these days with CQL -- the consistency and data models are just different to allow for writes to scale up) Not saying Mongo doesn't have any legitimate uses (although I honestly suspect it doesn't, not even the ones listed at the end of TFA, at least not assuming the developer is already well versed in using a good relational database and related tooling. In fact I think I'd be willing to challenge and bet money against a mongo proponent to see who could create "an MVP on a super-tight schedule" faster.)