6 ms·

What is your actual objection to databases? SQL is a skill, and not a hard one. Develop it once, and its availability becomes a benefit. Relations are trivia

by btilly 4y ago

What is your actual objection to databases? SQL is a skill, and not a hard one. Develop it once, and its availability becomes a benefit. Relations are trivial once you have the skill of SQL. Foreign keys are entirely optional sanity checks. Ignore them. SQLite comes built in to all your favorite languages, and no need for docker-compose. And all the other things, like letting the database protect you from race conditions, recovering from crashes and the like, are good.

arpa 4y ago
Ignore sanity checks, best advice ever!
- btilly 4y ago
  If a person is struggling with the basics, "you must learn all the things at once" isn't great advice. Reduce scope. Also foreign keys are a mixed bag. See https://stackoverflow.com/a/83393/585411 https://stackoverflow.com/a/83393/585411 for some of the pluses and minuses. I've seen very experienced people in significant projects go both was on the value of foreign keys. And a lot of the complications are more of a barrier for people who are just learning. I've personally been on both sides of this fence.
  - deleted 4y ago
    [deleted]
  - arpa 4y ago
    I'm afraid imma have to disagree with ya here dude
    - btilly 4y ago
      Care to offer any arguments beyond it being your opinion? For the record, I first encountered arguments against foreign keys around 20 years ago from a VERY experienced Oracle DBA. He knew what he was talking about, and had actually written some of the courses that Oracle used to certify DBAs. He pointed out that our transactional database for our high volume website was already pushing the limits of what our hardware could do. Maintaining unnecessary indexes or integrity constraints was going to take our database down. Since then I've kept track. And found that the benefits versus downsides are more finely balanced than I would have guessed.
divan 4y ago
While I agree with what you've said, but "skill of SQL" makes me cringe. It sounds like some fundamental skill, like running or swimming. But it's more like "navigating your local govt bureucracy skill" – you generally better off when you have it, but there is nothing to be proud about. SQL as a query language is truly horrible once you get past simple data queries. Most people never question if SQL is even good for its job, or if there is an alternative to the SQL, and blindly work on their SQL skills. It's still better than working on the "MongoDB skills", though. But in 2022 the DB interfaces exploration space is expanding, and there are some good alternatives to SQL to learn too.
- ajfriend 4y ago
  What are some good alternatives to SQL?
  - divan 4y ago
    EdgeQL is surprisingly good in practice
- btilly 4y ago
  SQL as a query language is truly horrible once you get past simple data queries. Oh, really? I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. I've also had to take what had been SQL queries and rewrite them in a variety of other ways outside of SQL. And vice versa. SQL feels horribly verbose, right until you compare it with equivalent procedural code. I'm confident in my ability to match or beat the SQL optimizer, I know that doing so will take me significant extra work. And I've seen enough code to know that most developers are unable to do so. The only tools that I've seen that come close to SQL are themselves thin wrappers around SQL. And I've yet to see them not lose some important capability that SQL has. For example analytic queries (aka window functions) are not often available in other tools.
  - divan 4y ago
    > I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. How does it refute the argument about SQL being horrible for data query? Being proficient in some language or tool doesn't necesarilly mean that thing is not horrible. There are a lot of people proficient in JavaScript, you know. To expand a bit on my definition of horrible, I see a tool as a good choice for its job when two criteria match: 1) tool was deliberatly designed for the job (and not used as an afterthought, as with html/css/js, for example) 2) it matches well the mental model of human thinking in that problem domain. For example, when I need to fetch some nested data from db, I think about my request in terms of relations between objects (like "give me the list of people who are the actors for those movies nominated for Oscars and who are started directors careers recently") instead of JOINS and GROUPS. The fact that I have to reshape my way to think (aka boost my SQL skills) is a testimony to how poorly it scores in my number 2 criteria. Basically whenever you need to reshape your thinking to do some simple stuff with a tool, the tool is horrible. Like describe relatively simple spatial abstract knowledge in terms of class hierarchies (and start thinking in classes, which is not how human brain organizes knowledge). Or build modern UX interfaces thinking in typesetting primitives like "<p>" or "<img 'src='". A lot of popular things are horrible in software engineering unfortunately.
Kinrany 4y ago
Since we're talking about SQLite: there is no reason the database library should be responsible for the query language, is there? Give me a database that has all those other things except SQL.

by btilly 4y ago

arpa 4y ago

Ignore sanity checks, best advice ever!

btilly 4y ago
If a person is struggling with the basics, "you must learn all the things at once" isn't great advice. Reduce scope. Also foreign keys are a mixed bag. See https://stackoverflow.com/a/83393/585411 https://stackoverflow.com/a/83393/585411 for some of the pluses and minuses. I've seen very experienced people in significant projects go both was on the value of foreign keys. And a lot of the complications are more of a barrier for people who are just learning. I've personally been on both sides of this fence.
- deleted 4y ago
  [deleted]
- arpa 4y ago
  I'm afraid imma have to disagree with ya here dude
  - btilly 4y ago
    Care to offer any arguments beyond it being your opinion? For the record, I first encountered arguments against foreign keys around 20 years ago from a VERY experienced Oracle DBA. He knew what he was talking about, and had actually written some of the courses that Oracle used to certify DBAs. He pointed out that our transactional database for our high volume website was already pushing the limits of what our hardware could do. Maintaining unnecessary indexes or integrity constraints was going to take our database down. Since then I've kept track. And found that the benefits versus downsides are more finely balanced than I would have guessed.

divan 4y ago

While I agree with what you've said, but "skill of SQL" makes me cringe. It sounds like some fundamental skill, like running or swimming. But it's more like "navigating your local govt bureucracy skill" – you generally better off when you have it, but there is nothing to be proud about. SQL as a query language is truly horrible once you get past simple data queries. Most people never question if SQL is even good for its job, or if there is an alternative to the SQL, and blindly work on their SQL skills. It's still better than working on the "MongoDB skills", though. But in 2022 the DB interfaces exploration space is expanding, and there are some good alternatives to SQL to learn too.

ajfriend 4y ago
What are some good alternatives to SQL?
- divan 4y ago
  EdgeQL is surprisingly good in practice
btilly 4y ago
SQL as a query language is truly horrible once you get past simple data queries. Oh, really? I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. I've also had to take what had been SQL queries and rewrite them in a variety of other ways outside of SQL. And vice versa. SQL feels horribly verbose, right until you compare it with equivalent procedural code. I'm confident in my ability to match or beat the SQL optimizer, I know that doing so will take me significant extra work. And I've seen enough code to know that most developers are unable to do so. The only tools that I've seen that come close to SQL are themselves thin wrappers around SQL. And I've yet to see them not lose some important capability that SQL has. For example analytic queries (aka window functions) are not often available in other tools.
- divan 4y ago
  > I've personally written SQL queries for complex purposes of lengths up to around 1000 lines. How does it refute the argument about SQL being horrible for data query? Being proficient in some language or tool doesn't necesarilly mean that thing is not horrible. There are a lot of people proficient in JavaScript, you know. To expand a bit on my definition of horrible, I see a tool as a good choice for its job when two criteria match: 1) tool was deliberatly designed for the job (and not used as an afterthought, as with html/css/js, for example) 2) it matches well the mental model of human thinking in that problem domain. For example, when I need to fetch some nested data from db, I think about my request in terms of relations between objects (like "give me the list of people who are the actors for those movies nominated for Oscars and who are started directors careers recently") instead of JOINS and GROUPS. The fact that I have to reshape my way to think (aka boost my SQL skills) is a testimony to how poorly it scores in my number 2 criteria. Basically whenever you need to reshape your thinking to do some simple stuff with a tool, the tool is horrible. Like describe relatively simple spatial abstract knowledge in terms of class hierarchies (and start thinking in classes, which is not how human brain organizes knowledge). Or build modern UX interfaces thinking in typesetting primitives like "<p>" or "<img 'src='". A lot of popular things are horrible in software engineering unfortunately.

Kinrany 4y ago

Since we're talking about SQLite: there is no reason the database library should be responsible for the query language, is there? Give me a database that has all those other things except SQL.