3 ms·

Clickbait-y or not, it sums up the feelings of a lot of developers. I don't understand it myself, but it seems a lot of developers want to reinvent the database

Clickbait-y or not, it sums up the feelings of a lot of developers. I don't understand it myself, but it seems a lot of developers want to reinvent the database to create something "better" or just find some way to never have to use SQL.

j45 9y ago
Using SQL and being able to think both relationally and non-relationally are a valuable skill. Working with text based datasets is a skill I don't see enough of even though it is quite prevalent. (I have spent more time than I've wanted using tools like Monarch to make text databases relational through an automated workflow) The reality of development is working with an existing, or multiple datasets homogeneously. Cool use of the JOIN command, a title like "Join text files using the command line" probably would receive a positive response here. It'd be sweet if everything was a nice and clean API data call with a bow on it, but part of being a developer is enabling that where it need to be.
- wallstprog 9y ago
  Like I said above, the title is bit of a joke, and a tease. If you read my blog, you'll see that I try to keep things light. (No cat pictures, though -- at least not yet ;-) Having said that, the description in the header is "Data manipulation with plain text files". Maybe I'll see if I can find a way to show that on GitHub ...
  - j45 9y ago
    Oh, I read the post, I assure ya. My beef is the binary link baityness of folks being one way or the other.
MaulingMonkey 9y ago
SQL seems to target a weird niche to me. Basic language containers (arrays, lists, etc.) tend to be much more convenient for lightweight data. No server to install configure and secure - everything can just live in code and the occasional serialized file. On the more heavyweight side of things, SQL isn't really amenable to GPUs - problematic for some heavyweight data crunching, or even basic computer graphics. It starts to make sense in the context of a server farm, but leaving it publicly exposed to the internet is a security fail - so the first thing you do with this networked appliance is lock it down to only be accessible from your server farm, or even just your local server via loopback if you're feeling particularly paranoid - writing your own layer that exposes a severely restricted API that only allows the exact operations you want to permit against your database. A lot of people will get this far and then still contribute to the CVE statistics on SQLI vulnerabilities, despite parameterized queries solving this problem. Or store blobs and defeat most of the point of using SQL in the first place. Or denormalize and shard their database for scaling purposes, losing many of the benefits of SQL enforced invariants in the process. It's not so much that I keep reinventing SQL on my projects, so much as I keep failing to come up with a good excuse to reinvent my existing approaches in SQL.

j45 9y ago

Using SQL and being able to think both relationally and non-relationally are a valuable skill. Working with text based datasets is a skill I don't see enough of even though it is quite prevalent. (I have spent more time than I've wanted using tools like Monarch to make text databases relational through an automated workflow) The reality of development is working with an existing, or multiple datasets homogeneously. Cool use of the JOIN command, a title like "Join text files using the command line" probably would receive a positive response here. It'd be sweet if everything was a nice and clean API data call with a bow on it, but part of being a developer is enabling that where it need to be.

wallstprog 9y ago
Like I said above, the title is bit of a joke, and a tease. If you read my blog, you'll see that I try to keep things light. (No cat pictures, though -- at least not yet ;-) Having said that, the description in the header is "Data manipulation with plain text files". Maybe I'll see if I can find a way to show that on GitHub ...
- j45 9y ago
  Oh, I read the post, I assure ya. My beef is the binary link baityness of folks being one way or the other.

MaulingMonkey 9y ago

SQL seems to target a weird niche to me. Basic language containers (arrays, lists, etc.) tend to be much more convenient for lightweight data. No server to install configure and secure - everything can just live in code and the occasional serialized file. On the more heavyweight side of things, SQL isn't really amenable to GPUs - problematic for some heavyweight data crunching, or even basic computer graphics. It starts to make sense in the context of a server farm, but leaving it publicly exposed to the internet is a security fail - so the first thing you do with this networked appliance is lock it down to only be accessible from your server farm, or even just your local server via loopback if you're feeling particularly paranoid - writing your own layer that exposes a severely restricted API that only allows the exact operations you want to permit against your database. A lot of people will get this far and then still contribute to the CVE statistics on SQLI vulnerabilities, despite parameterized queries solving this problem. Or store blobs and defeat most of the point of using SQL in the first place. Or denormalize and shard their database for scaling purposes, losing many of the benefits of SQL enforced invariants in the process. It's not so much that I keep reinventing SQL on my projects, so much as I keep failing to come up with a good excuse to reinvent my existing approaches in SQL.