4 ms·
The argument in the paper is that data professionals -- 9ncluding yourself -- do not understand data fundamentals, for which reason they blame "poor performance
by sgeneris 10y ago
The argument in the paper is that data professionals -- 9ncluding yourself -- do not understand data fundamentals, for which reason they blame "poor performance" on the RDM. But RDM and normalization are purely LOGICAL and as the article states, performance is determined exclusively by PHYSICAL implementation. So the article does imply that on rare occasion you may be forced to denormalize WITH EXISTING SQL IMPLEMENTATIONS, but this has nothing to do with the RDM and normalization and everything to do with SQL implementations which are not relational, do not have proper support of physical independence and are not versatile enough at the physical level.
- jasode 10y ago>data professionals -- 9ncluding yourself -- do not understand data fundamentals, for which reason they blame "poor performance" on the RDM. I don't blame poor performance on the mathematical purity of logical relations between entities. >the article does imply that on rare occasion you may be forced to denormalize You didn't read the article carefully enough. You overlooked how the author seemed to allow for denormalization but he immediately negated the followup dev work as "never justified": " -- and performance is still unsatisfactory. You denormalize and, as Bolenok recognizes, introduce redundancy. [..] - but they would never be justified:"
- emmelaich 10y agoGiven a fully normalized db and a query which has to join say ten tables - what physical implementation would optimise this query?