3 ms·
This still fall in the trap of paint RDBMS as "scary" and more "complex" to use: > The truth is that relational databases scale up just fine when placed in the
by mamcx 8y ago
This still fall in the trap of paint RDBMS as "scary" and more "complex" to use:
> The truth is that relational databases scale up just fine when placed in the hands of people that (1) know what they are doing, (2) aren’t afraid to learn new things, and (3) don’t mind doing the work necessary
This is true FOR ANY KIND OF DATABASE.
In fact, a RDBMS is far easier to use because it TAKE CARE OF THE HARDEST THINGS OF COMPUTER DEVELOPMENT. Good luck for the average joe to understand ACID and try to implement it on top of Mongo.
RDBMS are for everyone
NoSql are for Pros.
- JackCh 8y agoMost RDBMS's got a well deserved reputation for "scary and complex" because they are enterprise grade software serious enough to have an entire career named after their administration. Much of the resources you'll find about these databases is written with the assumption that the reader is in that career track, which often isn't true. This of course has nothing to do with the relational model, and teaching a newbie to use sqlite is a good way of demonstrating that.
- mamcx 8y agoThis is true. Ironically Access and/or FoxPro was a good way to introduce people to it.
- jchanimal 8y agoAs someone who participated in building the first wave of NoSQL, I have to agree with the sentiment here. Except tabular inflexibility hits everyone. I wrote a blog post about how FaunaDB offers the best of relational and NoSQL models here: https://blog.fauna.com/unifying-relational-document-graph-and-temporal-data-models https://blog.fauna.com/unifying-relational-document-graph-an...
- mamcx 8y agoAs hobby I'm building a relational language, and think the problem that the RDBMS folks have overlooked is how operate in partail relations (like slices or tables with less + more fields). You are set with the initial schema and that is. Is not easy to store arbitrary portions of relations, not is even easy to operate in-memory instead. Plus, the fact the DB is far from the code miss a lot of oportunities. In my mind, I think the solution is not to have a "database language + storage far away" but code all the app with a embebed db. Is not as weird as it sound. This is how we operate with foxpro.