Earlier quoted context omitted.
>I have issues with his "Reasons to use NoSQL" Looking at the author bio at the bottom, I believe it is "her".
God, this shit again.
Please don't post unsubstantive comments.
SQL vs. NoSQL Databases: What’s the Difference?
51–60 of 60 posts
Re: SQL vs. NoSQL Databases: What’s the Difference?
#52Earlier quoted context omitted.
God, this shit again.
Please don't post unsubstantive comments.
Pointing out a gender discrepancy in a thread that doesn't discuss gender at all is "unsubstantive".
Adds nothing to the conversation and is actually incorrect, as male is the default gender for pronouns.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#53Earlier quoted context omitted.
SQL migrations may seem tedious, but the process of planning your data model and having rigid definitions for your data types saves you huge amounts of time in the long run. Your reasoning seems too black and white, most the of the time, you can't know your data model ahead of time, that's why prototypes are so useful, so just using your language data structures or some less rigid datastore lets you get quicker to yo…
This sounds so logical, is repeated often, and is fundamentally incorrect. Just because you are defining a data model doesn't mean you can't change it. There's nothing easier. Undefined schemas are actually worse under change than defined ones.
Like I've argued before, you have a schema. Your app cares about the location and format of the data. You're only deciding whether or not you want to write down your schema and use it to catch mistakes.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#54Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure-functional, side-effect-free programming language that's actually gone mainstream [0]. If you look carefully at the APIs of the "No SQL" databases, you'll find them introducing relational set theoretic features. To paraphrase Paul Graham's unbearably smug com…
NoSQL DBs became popular because performant distributed joins are hard. Joins (and aggregate, group by, etc.) were thrown out to make horizontal scale out simpler. Cassandra CQL, for example, shares keywords with SQL, but the key-value(ish) data model couldn't be more different, and is much easier to scale horizontally. Various systems are trying to solve the distributed join problem while keeping easy horizontal sca…
Yep. I spent 2.5 years at MemSQL, which nailed its colors to the mast of solving distributed joins via good old SQL. It is absolutely possible to have fast scaled distributed SQL, and a pony. The caveats are falling away one by one.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#55Earlier quoted context omitted.
Having rigid definitions for data types doesn't necessarily mean the datastore is rigid. It just means that you know what type of data goes in each column. Like it or not, if you change your schema that change has to be handled somewhere - either you update the old data to the new schema (do this), or you handle old versions of the schema in the application (fundamentally non-scalable IMO). It doesn't matter whether…
That is why I mentioned prototypes, they are a quick messy hack that is not meant to scale, its purpose its to validate your ideas and decisions, what is going to become your MVP, which IMO is far more important than getting the perfect stack/tooling from the start.
We obviously value very different things in regards to software development.
You really seem to favor initial velocity and rapid iteration. Fair, I can totally understand why.
I favor planning, stability, and limiting thrash due to bad/uninformed decision making.
In my experience the rush to market only pans out when you plan on having a large influx of funding to rebuild your stack. Otherwise you are stuck holding a mess of code and trying to scale ideas that never should have gone to production in the first place.
There is a whole other side to the industry that demands provably correct solutions, and will not tolerate the "hacker culture". Not because of any petty reasons like work hours or perks, but because some applications require a level of accuracy that your average growth hacker can't meet.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#56Earlier quoted context omitted.
Another point on rapid development: SQL databases have some amazing libraries and tooling. I've been working a lot with SQLAlchemy in Python lately and have been blown away by it. > While NoSQL databases may not force you into a schema for your database, you will pay a toll for this mutability in your application layer. A while ago I read a really good point on this: There's always a schema. NoSQL / "schemaless" data…
NoSQL databases have as many schemas as there have been changes to the model. Everytime you make a change, and are keeping old data, you have another schema. Your code then has to be aware of every schema that has ever existed. Over time this becomes more and more painful and error-prone. In a relational database, you have one schema and you have to convert/update your data to match that schema whenever it changes. I…
Imagine handling data like that with javascript.
Mutable data types, with mutable data, and inconsistent error handling.
Burned me out in a matter of months.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#57Earlier quoted context omitted.
This sounds so logical, is repeated often, and is fundamentally incorrect. Just because you are defining a data model doesn't mean you can't change it. There's nothing easier. Undefined schemas are actually worse under change than defined ones.
Like I've argued before, you have a schema. Your app cares about the location and format of the data. You're only deciding whether or not you want to write down your schema and use it to catch mistakes.
Like I've argued before, with NoSQL you have many schemas -- one for every change (unless you delete all the data after every schema change). In SQL, you have one schema -- which is much easier to work with even when you're just doing early spec development.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#58Earlier quoted context omitted.
Honestly I'd still prefer to go other way -- from the relational database models you get your APIs defined and correct and then the screens and elements are obvious. I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.
IMO it's dead easy to create APIs from a database schema, where that schema underpins your monolith and you're opening said monolith up to the outside world, and you don't really care too much what goes on out there. But if you're building a system which is not a monolith, and instead is made of up of, say, 20 services, then putting good boxes around those services and defining the lines that connect them (the APIs)…
I can't really disagree with that. I usually design micro-services the same as do monoliths; it's just the client is different (another service).
Re: SQL vs. NoSQL Databases: What’s the Difference?
#59The article read like it is written by someone who has never understood how to use a SQL database. To quote Mr Torvalds himself: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Something that i struggled with before i learned how to use a SQL/relational database was to actualy use the database relations in my code. I first specified the relations in the da…
On this topic I'd like to plug a book that really drove this home for me: "SQL Antipatterns" by Bill Karwin.
Re: SQL vs. NoSQL Databases: What’s the Difference?
#60For me, the most important difference is that a SQL "Database" is actually an incredibly powerful application server, with a built in compiler for a data processing language, and many years of development on access strategies, whereas a NoSQL database is just a level above an http server with an index that scales really well. That's a bit of an exaggeration, but I find it helps new teams understand the big picture. In a microservice environment, I encourage my teams to think of their SQL database server as a microservice, not a persistence store.