| |||||||||||||
Cool new Free softwareCool new Free softwarePosted Dec 25, 2012 5:26 UTC (Tue) by raven667 (subscriber, #5198)In reply to: Cool new Free software by man_ls Parent article: Status.net service to phase out, replaced by pump.io
> You can try to use PostgreSQL as a NoSQL store, but you will be swimming upstream for the rest of your career. How do you share the load, or replicate between nodes? How do you deal with consistency if you need it in a non-relational table? How do you optimize a single database for both consistency and lack of it?
There are certainly specific use cases that the various NoSQL databases were designed for and are optimized for, if you have one of those cases then by all means use the right tool for the job, but there seem to be a lot of inexperienced developers who think that traditional SQL databases are slow creaking dinosaurs, unsuitable for any purpose when in fact they contain highly optimized data stores which have been developed over decades by people competent in the relevant math and computer science. Different does not always mean better.
(Log in to post comments)
Cool new Free software Posted Dec 25, 2012 17:38 UTC (Tue) by man_ls (subscriber, #15091) [Link] Well, designing a relational database is not trivial: modeling n-m relationships can be challenging for beginners. On the other hand, using a document store like MongoDB is trivial until you get to the serious stuff -- or to transactions. No wonder it is the most popular of the NoSQL bunch.Other NoSQL families, like key-value (Dynamo-like) or graph databases, are more specialized and need more effort to keep going. But I would argue that none are near the level of sophistication of a normalized database. Most of you probably don't feel it because you have worked with SQL for many years, but it is a contorted language that uses a highly unnatural data model. Yes, relational databases are highly optimized, but you pay the price every time you read or write anything to them.
Cool new Free software Posted Dec 25, 2012 17:56 UTC (Tue) by Wol (guest, #4433) [Link]
Which is why it sounds like Pick is a good fit for people who understand both relational and NoSQL.
Your "contorted language" is spot on. Basically, in relational you cannot STORE that most natural of data concepts, the list. You have to MODEL it. At which point your database becomes unnecessarily complex and complicated.
Referring back to the comment in your earlier post about "You can either read everything from many different "tables" or you can just store every piece of data multiple times. With relational databases you can also denormalize data, but they are usually less flexible as to how it is stored."
But that's exactly what Pick does! NFNF is what relational purists would call "denormalised". The fact that it can be mechanically normalised by the DB seems to have passed them by. So in Pick, I don't "read from many tables OR store the data many times", I just store the data ONCE in ONE table. imho it is *relational* that needs to "store the data many times in many tables" - just try to store a list, then ask yourself how many times you have to store the name of the list (or its id, the same thing...) As a system that requires (as part of its definition) that you don't store duplicate data, the relational system is very poor at living up to its own definition!
Cheers,
Cool new Free software Posted Jan 4, 2013 16:56 UTC (Fri) by nix (subscriber, #2304) [Link]
I might note that you can in fact store lists in PostgreSQL. It's had arrays since before it was called PostgreSQL. :)
|
|||||||||||||