mysql - SQL generalization/specialization, data redundancy -
i have 3 tables: actions, messages, likes. defines inheritance, messages , likes actions' childs (specialization).
message , both have column userid , createdat. should of course moved parrent table action , removed message , likes. there's 1 case when need select both messages , likes database, in other cases select 1 of them, either messages or likes.
is ok duplicate userid , createdat in child , parrent table? costs disk space saves 1 join - have join messages, likes actions everytime needed userid , createdat. whatsmore need change current code...
what suggest?
in opinion case of premature optimization (or premature denormalization, if prefer). you're guessing join overhead cause significant problems, you're guessing duplicating userid , createdat columns in dependent tables improve performance significantly.
i suggest should not duplicate columns until know there's real problem. keep few observations on performance optimization tacked on wall remind myself of should in similar cases:
- it ain’t broke ‘til it’s broke.
- you can’t improve haven’t measured.
- programs spend surprising amounts of time in damnedest places.
- make run. make run right. make run right fast.
- optimization literally last thing should doing.
- doing things wrong faster no great benefit.
also few comments on denormalization:
- you can’t denormalize not normalized.
- most developers wouldn’t know third-normal form if leapt out behind screen, screamed banshee, , cracked baseball bat on heads.
- denormalization suggested panacea database performance issues. problem recommending denormalization have never normalized anything.
- “denormalization performance reasons” excuse sloppy, “do we’ve done” thinking, when such denormalization enshrined in design.
in experience, not able identify performance problems occur before writing code. problems seem occur in places never have thought look. thus, i've found best choice write simplest, clearest code can , design database can, following normalization rules best of ability, , deal turns up. there may still performance issues need attention (but, surprisingly, not often), in end i'll end simple, clear, , understood/maintained code, running on simple, well-designed database.
share , enjoy.
Comments
Post a Comment