6 ms·

In 2004, I started community college program and had a professor teaching intro to databases. He was retired from industry and had lived through the rise of RDB

• blahyawnblah 4y ago
  > don't prematurely optimize Premature optimization is the root of all evil
  • zinclozenge 4y ago
    So is premature pessimization.
  • isaacremuant 4y ago
    Careful with repeating mantras without reflection. You may end up using them as arguments when they're just catchphrases that require context. See people who used "goto considered harmful" as an absolute to never use goto (C).
  • hnuaer 4y ago
  • branko_d 4y ago
    “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
    • kcartlidge 4y ago
      How dare you bring full quotes and context to a discussion :) Seriously true, though. What's usually missed is the first bit, about "small efficiencies", combined with the last bit, the "critical 3%". He's basically saying don't spend time in the mass of weeds until you know where the problems really are, but conversely take the time to optimise the smaller areas that are performance-critical. Almost the opposite of the carte-blanche overly-minimal MVPs often thrown together by those of us who forget what the V stands for.
• matchagaucho 4y ago
  Tuple table performance, though, tends to degrade quickly when querying separate rows for every little attribute. More _memory_ and row caching in RAM has allowed for a resurgence in denormalized schema. FB's underlying schema is similarly just a few tables. But the entire dataset is memcached.
  • marginalia_nu 4y ago
    > Tuple table performance, though, tends to degrade quickly when querying separate rows for every little attribute. Interesting. Do you know what causes this steep decline in performance? A larger sequential read is typically not that much slower regardless on what sort of drive you are using. I'd have expected that the random access pattern of a normalized table would lose out.
• pc86 4y ago
  "Performance is good" is I think something everyone could agree with just hearing it for the first time. There's no reason to prefer worse performance if you can have better performance for no additional cost. Is the same true for normalization? Why is just the state of being more normalized inherently better?
  • bsedlm 4y ago
    because a normalized database repeats less things and is much easier to understand than a messy one. oh, and also, the entire point is that neither is "inherently better"... both have pros and cons
    • pc86 4y ago
      I think my point was "performance" in the sense of faster response time is inherently good. All things being equal, if you have a more performant option you'll choose that. The only time you accept worse performance is in pursuit of some other metric. On the flip side, "normalization" doesn't have that same inherent good-ness. All things being equal (including performance) there isn't any inherent drive toward more normalization, maybe because a faster performing page will have clear impact to the user while a more normalized data structure would be completely transparent to the user?
      • bsedlm 4y ago
        sure, from the perspective of the final user it doesn't matter much at all. with my point about normalization being easier to understand I meant to say that it is easier for a developer learning about the schema. if I recall ok, I think there's also something about data de-duplication in a normalized database. without this normalization, you could get a lot of repetition, which would actually require to update the same data in multiple places or find some other way to deal with different data about the same entity (some sort of de-synchronization is more likely without normalized schemas). in any case, I'll grant you that normalization should never be 'the' goal for a database.
  • jeremyjh 4y ago