91–100 of 101 posts
Earlier quoted context omitted.
It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".
But let's not forget that schema-less databases are often marketed as noSQL, so typing sql (quicker on phone) should be acceptable imo.
Earlier quoted context omitted.
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.
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 transacti…
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.
Earlier quoted context omitted.
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…
> 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,…
Earlier quoted context omitted.
> 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,…
I meant to suggest instead that we fix languages, and now that I think of it .net's linq is not bad.
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 h…
Earlier quoted context omitted.
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 transacti…
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 i…
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
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 h…
Then why are we only singling out Mongo. Doesn't this also apply to other NoSQL stores.
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.)
Earlier quoted context omitted.
May I ask why would you insist on such a thing? Is it about avoiding SQL?
I'd like access to JSON Schema's impressive tooling. I haven't seen anything like this for SQL schemas: http://jeremydorn.com/json-editor/ (Though if it exists please tell me, I'd be very interested!)
One very good, which I extensively used in my previous position was DevExpress (https://www.devexpress.com/Products/NET/Controls/WPF/Editors...).
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
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 sent…
It is a dead giveaway for inexperience, that some people refer to relational databases as "SQL databases".