5 ms·

Having migrated a postgres database to dynamodb, I would say that I'm never going to use postgres again. The problem with all SQL databases is that they are to

Having migrated a postgres database to dynamodb, I would say that I'm never going to use postgres again. The problem with all SQL databases is that they are too easy to query and use. You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it scale.

hnarn 7y ago
> You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it scale. Surely this depends on how you set up your SQL database to begin with? I'm not familiar with NoSQL, so can you explain why "schemas" aren't necessary and scaling happens automatically?
- me551ah 7y ago
  You could design a SQL database to be denormalized from the start, but then you are losing many of the advantages of a SQL database. I never said that schemas aren't necessary, just that using a strict NoSQL database forces you to think about scaling constraints early. This avoids(atleast partially) a schema redesign later.
  - g4nt1 7y ago
    Ah yes! Optimize early, that's what my teachers always told me to do. /s
    - lmm 7y ago
      Code is easy to change. Data schemata much less so, particularly in traditional SQL databases.
DeathArrow 7y ago
You don't have joins in NoSQL so you have to keep data denormalized. That means data isn't consistent and you can have an will have (at a high enough data volume) errors if you aren't extremely cautious on how you update and add new data. That might matter or not in a particular business case.
- GenericsMotors 7y ago
  I really hope the GP doesn't work on anything handling financial transactions.
  - DeathArrow 7y ago
    If speed it's only thing that matters, he can use /dev/null for writes and /dev/urandom for reads. That's also very scalable.
32gbsd 7y ago
Some say that scaling is a edge case. what say you?
cooervo 7y ago
lol this is the dumbest comment ever

hnarn 7y ago

> You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it scale. Surely this depends on how you set up your SQL database to begin with? I'm not familiar with NoSQL, so can you explain why "schemas" aren't necessary and scaling happens automatically?

me551ah 7y ago
You could design a SQL database to be denormalized from the start, but then you are losing many of the advantages of a SQL database. I never said that schemas aren't necessary, just that using a strict NoSQL database forces you to think about scaling constraints early. This avoids(atleast partially) a schema redesign later.
- g4nt1 7y ago
  Ah yes! Optimize early, that's what my teachers always told me to do. /s
  - lmm 7y ago
    Code is easy to change. Data schemata much less so, particularly in traditional SQL databases.

DeathArrow 7y ago

You don't have joins in NoSQL so you have to keep data denormalized. That means data isn't consistent and you can have an will have (at a high enough data volume) errors if you aren't extremely cautious on how you update and add new data. That might matter or not in a particular business case.

GenericsMotors 7y ago
I really hope the GP doesn't work on anything handling financial transactions.
- DeathArrow 7y ago
  If speed it's only thing that matters, he can use /dev/null for writes and /dev/urandom for reads. That's also very scalable.

32gbsd 7y ago

Some say that scaling is a edge case. what say you?

cooervo 7y ago

lol this is the dumbest comment ever