4 ms·

In what way is this guide 'humble'? Seems fairly self-confidently opinionated to me.

kbenson 7y ago
These are really the basics of database design. I would argue that you should do these until you know when you shouldn't. That is, you should normalize to this level until you learn when and why to denormalize some things for performance, if that's ever even needed. I think it means "humble" as in not trying to teach anything complex or revolutionary.
redis_mlc 7y ago
I'd agree. The advice to use NULL is usually harmful, and constraints are not high-performance. One nitpick is that "user" is a reserved word in PG, so "users" is better. Other than that, I'd agree with most suggestions. But I'd use MySQL. :) Source: DBA.
- purerandomness 7y ago
  Please don't use databases that don't support transactional schema changes. You will hate everything about it.
  - tomnipotent 7y ago
    Facebook, Google, and many other companies run massive MySQL deployments and are doing just fine.
    - ReidZB 7y ago
      They do, and obviously it is workable, but I think every big MySQL org ends up with a tool/workflow like gh-ost: https://github.com/github/gh-ost https://github.com/github/gh-ost which have their own set of challenges, like not playing well with foreign keys.
      - evanelias 7y ago
        Big MySQL orgs are sharded, which greatly reduces the utility of foreign key constraints anyway.
      - kbenson 7y ago
        Or the Percona tools, which support stuff like online schema change.
    - nightski 7y ago
      They also have massive engineering budgets.
    - purerandomness 7y ago
      Given unlimited VC money to burn, I could engineer a high-traffc SaaS running on a beowulf cluster of Juiceros. Would that be a good idea? Maybe.
      - tomnipotent 7y ago
        This is a silly argument. Facebook & Google have made massive investments into the source code of MySQL and have helped make massive operational improvements to it over the last decade. It's always glaringly obvious when people have no experience with something and then throw shade at it, like the obligatory Microsoft-bash whenever that topic comes up.
- zenhack 7y ago
  The article actually advises setting fields to NOT NULL unless there's a specific reason to do otherwise. And re constraints: eh, for most applications this feels like premature optimization. My usual approach is to include whatever constraints are easy to express, but also have the application not rely on the DB for enforcement. That way you get some extra safety checks that might catch bugs, but if they do become a bottleneck you can just drop them. Not a DBA, just a software dev who's learned not to sacrifice safety for perf unless there's a clear, demonstrable need.
- kbenson 7y ago
  > The advice to use NULL is usually harmful The advice is to set NOT NULL if you think the field can't be null. That's valid, and a matter of encoding the schema to correctly match the data. Same with check values. Keep bad data out of the database wherever you can. > and constraints are not high-performance Then turn off constraint checking after you've built your schema and identified them as a performance problem. Don't optimize away your data integrity before you've even determined it's a problem. If you actually don't care about your schema, just use a text field and throw whatever in it, or use a document store without any strict checking. If you're using SQL, presumably you're using it for a reason, and that's likely so you can take advantage of what it has to offer.
  - helloiloveyou 7y ago
    Hey thanks for clarifying it for the other user! I also agree with everything that you're saying, in this and other comments in the thread

These are really the basics of database design. I would argue that you should do these until you know when you shouldn't. That is, you should normalize to this level until you learn when and why to denormalize some things for performance, if that's ever even needed. I think it means "humble" as in not trying to teach anything complex or revolutionary.

redis_mlc 7y ago

I'd agree. The advice to use NULL is usually harmful, and constraints are not high-performance. One nitpick is that "user" is a reserved word in PG, so "users" is better. Other than that, I'd agree with most suggestions. But I'd use MySQL. :) Source: DBA.

purerandomness 7y ago
Please don't use databases that don't support transactional schema changes. You will hate everything about it.
- tomnipotent 7y ago
  Facebook, Google, and many other companies run massive MySQL deployments and are doing just fine.
  - ReidZB 7y ago
    They do, and obviously it is workable, but I think every big MySQL org ends up with a tool/workflow like gh-ost: https://github.com/github/gh-ost https://github.com/github/gh-ost which have their own set of challenges, like not playing well with foreign keys.
    - evanelias 7y ago
      Big MySQL orgs are sharded, which greatly reduces the utility of foreign key constraints anyway.
    - kbenson 7y ago
      Or the Percona tools, which support stuff like online schema change.
  - nightski 7y ago
    They also have massive engineering budgets.
  - purerandomness 7y ago
    Given unlimited VC money to burn, I could engineer a high-traffc SaaS running on a beowulf cluster of Juiceros. Would that be a good idea? Maybe.
    - tomnipotent 7y ago
      This is a silly argument. Facebook & Google have made massive investments into the source code of MySQL and have helped make massive operational improvements to it over the last decade. It's always glaringly obvious when people have no experience with something and then throw shade at it, like the obligatory Microsoft-bash whenever that topic comes up.
zenhack 7y ago
The article actually advises setting fields to NOT NULL unless there's a specific reason to do otherwise. And re constraints: eh, for most applications this feels like premature optimization. My usual approach is to include whatever constraints are easy to express, but also have the application not rely on the DB for enforcement. That way you get some extra safety checks that might catch bugs, but if they do become a bottleneck you can just drop them. Not a DBA, just a software dev who's learned not to sacrifice safety for perf unless there's a clear, demonstrable need.
kbenson 7y ago
> The advice to use NULL is usually harmful The advice is to set NOT NULL if you think the field can't be null. That's valid, and a matter of encoding the schema to correctly match the data. Same with check values. Keep bad data out of the database wherever you can. > and constraints are not high-performance Then turn off constraint checking after you've built your schema and identified them as a performance problem. Don't optimize away your data integrity before you've even determined it's a problem. If you actually don't care about your schema, just use a text field and throw whatever in it, or use a document store without any strict checking. If you're using SQL, presumably you're using it for a reason, and that's likely so you can take advantage of what it has to offer.
- helloiloveyou 7y ago
  Hey thanks for clarifying it for the other user! I also agree with everything that you're saying, in this and other comments in the thread