5 ms·

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not n

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specifications. When you start seeing engineers have difficulty reasoning about what the data model should be and nobody willing to commit to one, it's the clearest sign that organizationally things are sour and you need to start having very firm and precise conversations with product.

potta_coffee 6y ago
I'm facing this issue now. App is supposed to deliver to clients after this sprint - and the data model still isn't locked down. After arguing through about 10 hours worth of meetings this week, I think I need a new job.
- busterarm 6y ago
  My condolences.
- theshrike79 6y ago
  The best thing about the lockdown is that you can apply, interview and change jobs without leaving your desk at home =)
ithrow 6y ago
It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specifications. Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?
- busterarm 6y ago
  You've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.
  - Falkon1313 6y ago
    Eh, not so much databases, but in terms of code, super flexible 'all things to all people' generic abstractions tend to be a lot more work and a lot more difficult to debug than a tight solution tailored to the problem it's solving, written in domain terminology. If only I had a nickel for every hour I've spent debugging abstractions and indirection that were just there for the sake of adding flexibility that would never be needed.
    - busterarm 6y ago
      I'm in agreement with you actually. I was badly suggesting that that kind of flexibility up front bites us in the ass later and it's a bad impulse often followed.
- tikhonj 6y ago
  You (mostly) don't have to deal with data migrations with statically typed languages. Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.
  - Chris_Newton 6y ago
    Releasing a new version of some code is usually easier than making structural changes to a database that's in active use. Yes, and on top of that, code-only changes need to be internally consistent to make sense but DB schema changes almost inevitably require some corresponding code change as well to be useful. Then you have all the fun of trying to deploy both changes while keeping everything in sync and working throughout.
- deleted 6y ago
  [deleted]
Shorel 6y ago
There are only two options for me: MySQL or Postgres. And using AWS generally means using Aurora. Then the choice is already made. Not hard at all. Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.
- orobinson 6y ago
  Just curious, for what reasons would you choose MySQL over Postgres?
  - kenhwang 6y ago
    Personally, when I want speed or easy upkeep and intend on doing dumb simple things. Postgres is more featureful, but if you don't intend on using those features, MySQL is consistently faster and historically smoother to update and keep running.
    - busterarm 6y ago
      Also in the Enterprise, if you're doing a lot of sharding and replication across networks, Percona MySQL is a very compelling product. I say that as a Postgres diehard.
    - twic 6y ago
      > MySQL is consistently faster Unless you want to do a join.
  - malinens 6y ago
    Probably the same way sometimes people choose sqlite versus mysql- simplicity. There are many cons and pros for both of them!
  - xorcist 6y ago
    Traditionally it was because you needed replication or sharding that you didn't have to boil half an ocean for, or at least half decent full text indices. These days however I believe the differences are smaller and in other areas. Most often, you choose a database because of what you application supports and is tested with, not the other way around. Or what your other applications already use. Complete green fields aren't all that common.
souprock 6y ago
Is every NoSQL database non-relational, and every relational database SQL? It sure seems to me that you could have a relational database without SQL. Something non-text could be nice. It might be a binary data format or compiled code. One might even convert SQL to binary query data at build time, with a code generator. It could work like PIDL, the code generator Samba uses to convert DCE/RPC IDL files to C source with binary data. Binary data goes over the wire. Another way is that both client code and server code could be generated, with the server code getting linked into the database server.
eecks 6y ago
Which parts are hard?

potta_coffee 6y ago

I'm facing this issue now. App is supposed to deliver to clients after this sprint - and the data model still isn't locked down. After arguing through about 10 hours worth of meetings this week, I think I need a new job.

busterarm 6y ago
My condolences.
theshrike79 6y ago
The best thing about the lockdown is that you can apply, interview and change jobs without leaving your desk at home =)

ithrow 6y ago

It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specifications. Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?

busterarm 6y ago
You've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.
- Falkon1313 6y ago
  Eh, not so much databases, but in terms of code, super flexible 'all things to all people' generic abstractions tend to be a lot more work and a lot more difficult to debug than a tight solution tailored to the problem it's solving, written in domain terminology. If only I had a nickel for every hour I've spent debugging abstractions and indirection that were just there for the sake of adding flexibility that would never be needed.
  - busterarm 6y ago
    I'm in agreement with you actually. I was badly suggesting that that kind of flexibility up front bites us in the ass later and it's a bad impulse often followed.
tikhonj 6y ago
You (mostly) don't have to deal with data migrations with statically typed languages. Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.
- Chris_Newton 6y ago
  Releasing a new version of some code is usually easier than making structural changes to a database that's in active use. Yes, and on top of that, code-only changes need to be internally consistent to make sense but DB schema changes almost inevitably require some corresponding code change as well to be useful. Then you have all the fun of trying to deploy both changes while keeping everything in sync and working throughout.
deleted 6y ago
[deleted]

Shorel 6y ago

There are only two options for me: MySQL or Postgres. And using AWS generally means using Aurora. Then the choice is already made. Not hard at all. Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.

orobinson 6y ago
Just curious, for what reasons would you choose MySQL over Postgres?
- kenhwang 6y ago
  Personally, when I want speed or easy upkeep and intend on doing dumb simple things. Postgres is more featureful, but if you don't intend on using those features, MySQL is consistently faster and historically smoother to update and keep running.
  - busterarm 6y ago
    Also in the Enterprise, if you're doing a lot of sharding and replication across networks, Percona MySQL is a very compelling product. I say that as a Postgres diehard.
  - twic 6y ago
    > MySQL is consistently faster Unless you want to do a join.
- malinens 6y ago
  Probably the same way sometimes people choose sqlite versus mysql- simplicity. There are many cons and pros for both of them!
- xorcist 6y ago
  Traditionally it was because you needed replication or sharding that you didn't have to boil half an ocean for, or at least half decent full text indices. These days however I believe the differences are smaller and in other areas. Most often, you choose a database because of what you application supports and is tested with, not the other way around. Or what your other applications already use. Complete green fields aren't all that common.

souprock 6y ago

Is every NoSQL database non-relational, and every relational database SQL? It sure seems to me that you could have a relational database without SQL. Something non-text could be nice. It might be a binary data format or compiled code. One might even convert SQL to binary query data at build time, with a code generator. It could work like PIDL, the code generator Samba uses to convert DCE/RPC IDL files to C source with binary data. Binary data goes over the wire. Another way is that both client code and server code could be generated, with the server code getting linked into the database server.

eecks 6y ago

Which parts are hard?