Recent Features
| |||||||||||||
Cool new Free softwareCool new Free softwarePosted Dec 25, 2012 17:38 UTC (Tue) by man_ls (subscriber, #15091)In reply to: Cool new Free software by raven667 Parent article: Status.net service to phase out, replaced by pump.io 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.
(Log in to post comments)
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. :)
|
|||||||||||||