like the yesterday's submission of "Why you should never use MongoDB (2013)" (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!
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.
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?
> 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.
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.
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?
Weird, speed of development and execution is exactly why/when I would reach for Just using a SQL based RDBMS.
Whereas, going to a non-relational solution would be something I'd do when I needed to trade away simplicity and consistency in exchange for scaling/performance for specific cases where relational can't handle the write load. Losing the schema and ability to do joins and arbitrary queries and assume transactionality is a big loss that requires lots of work.
A dirty secret of NoSQL is that sure, part of their target audience is legitimate needs, but another part of their target audience is just new developers who don't have much experience with either SQL or NoSQL databases, and are easily mislead into buying the idea that NoSQL will be easier Because There's No Schema or Joins To Think About
I'm starting to tune out whenever I hear someone saying "schemaless". There's always schema. The question is whether schema's enforced at write time, or if instead it needs to be dealt with at read time.
Schema on write is a hassle up front because you've got to start imposing a strict data model up front, possibly before you've even got a good idea what your information domain looks like. And every misstep will be immediately punished with a painful migration.
Schema on read is, IMO, a hassle in the long run because now any code that's consuming the data needs to be prepared to have the information come in any of the ways that it has ever been stored in the history of the database. If folks were being disciplined, then hopefully that's a small number. If they weren't, you may end up with either some sort of combinatorial explosion, or a situation where you've seriously got to null-check every little thing. Every misstep will forever be punished with a million tiny little if-statements nagging at you like endless paper cuts.
I suppose it's easy to guess where my crass sentiments lie.
Yeah, as for me you're preaching to the choir :-) But that's fun so I'll do it some more too
You don't get to just stop worrying about schemas, joins, and transactions in your database. If your database won't do those things for you, now YOU have to.
* No schema just means (as you nicely describe) your app deals with schema changes, not the database. Have fun.
* No joins just mean your app deals with the complex choreography of keeping denormalized tables up to date. You think that's easy? Have fun deciding what updates to make synchronously or asynchronously, what to compute where and when, making sure you don't screw up and either hose performance or end up with stale data in a dependent table... enough of this and you'll be dying to come back to a proper relational database where you can just CREATE MATERIALIZED VIEW and call it a day
* No transactions just means.... oh, who am I kidding, you're not going to bother to write your app carefully to deal with those consistency semantics (and if you do, you'll probably do it wrong), you're just going to ignore them, call it a day, and hope your product doesn't get popular enough that the race conditions start pissing people off.
* No SQL means instead you're probably going to use some protocol that's much newer, much less popular, and locks your app and your mental knowledge into a single specific database product. Have fun rewriting your whole database layer and relearning the whole API and data model when you realize FooDB might be a better fit than BarDB. And it's way easier to go from SQL to non SQL if you end up having to than the other way around
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.
Joins seriously have nothing to do with the CAP theorem, except inasmuch as multi-key read/write transactions do. Consistent multi-key read-only transactions and write-only transactions are actually not terribly difficult to do under serializability across partitions. Additionally, from a sheer performance and data perspective, centralized relational databases work just fine for real workloads. Unfortunately, pretty much zero real-world apps don't need multi-key read/write transactions, and modern businesses expect uptime that is unrealistic for a centralized system, so people are forced to replicate across datacenters. Ultimately what most people end up doing (regardless of database) is partitioning into small enough key groups that they can afford the highly expensive latency cost for maintaining high availability (across multiple datacenters) while maintaining consistency within each group for read/write transactions, and giving up on consistency across partitions for such operations (but usually maintaining consistency on read-only and write-only transactions). NoSQL can sometimes give you a clearer understanding of the cost/consistency tradeoff you're making, and hierarchical keys can make it much easier to partition, but joins really hardly enter into it.
> 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?
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.
Mongo doesn't solve the impedance mismatch either, if you have 2 classes which have a many to many relationship you'll still need to think about it when you model datas, without any guarantee of consistency. Mongo DB barely make queries easier to write, without the power of SQL. How would you persist a "recursive" model with MongoDB while being able to do aggregation operations on the collection , like counting the number of models ? if you use a single collection for all the models, you'll then have to load all the models in the application code and count them in the code, where a simple COUNT would do the trick. With Mongo you're constently trying to reinvent SQL in the code. On the other hand, SQL allows one to write recursive queries for tree like structures.
I understand the trade offs in order to scale, but you can give up on joins WHEN it's time to scale. Mongo doesn't give one the choice at first place.
SQL is a relatively popular programming language that lets you deal quite sanely with relational data.
Then there's Prolog, Kanren, Mercury… which are admittedly not especially popular.
The so-called “impedance mismatch” comes mostly from people who don't understand all that SQL can do and inevitably end up replicating it in some other language.
> 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.
The "Object-Relational impedance mismatch" is not a result of the supposed fact that "no programming language lets you deal with relational data sanely in code", its a result of the fact that industrially popular object-oriented languages, of the time when the term was coined, did not align well with the data model supported by then-existing relational databases, and vice versa.
The thing is, for the majority of deployments out there, developers don't even know what is the CAP theorem, nor do they need the theoretical performance NoSQL databases have over default configured RDBMS.
Just like all those big data deployments that can fit on an USB key and be processed by plain UNIX tools.
"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.)
> 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”.
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.)
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.
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.)
explain the presence of homosexuality in a population when the theory of evolution predicts that any such trait (which leads to much lower genetic fitness) would have disappeared a long time ago
one's homosexuality may improve fitness of one's family: if we're brothers and i'm homosexual, we won't be splitting resources between your and my children, and i'll be an extra "parent" looking after your kids. genetically speaking, that is still a (qualified) success for me.
also, genes don't give a damn about individual's reproduction, and local optima are rampant.
do not use -X without having read the manual, it can break redirects and other things.
from the curl(1) manpage:
-X, --request <command>
(...)
Normally you don't need this option. All sorts of GET, HEAD, POST and PUT requests are rather
invoked by using dedicated command line options.
This option only changes the actual word used in the HTTP request, it does not alter the way
curl behaves. So for example if you want to make a proper HEAD request, using -X HEAD will not
suffice. You need to use the -I, --head option.
The method string you set with -X will be used for all requests, which if you for example use
-L, --location may cause unintended side-effects when curl doesn't change request method
according to the HTTP 30x response codes - and similar.
PUT is indicated by using -T / --upload-file, POST by -d / --data or any --data-foo option (eg. --data-raw).
DELETE is the only HTTP method in the parent list that needs -X to be used.
Use the file name "-" (a single dash) to use stdin instead of a given file.
Alternately, the file name "." (a single period) may be specified instead of
"-" to use stdin in non-blocking mode to allow reading server output while
stdin is being uploaded.
syntax is important! ;)