----------------------------------------------------------------------------------
@MSGID: 3:633/10 ff67a521
@REPLY: 3:633/10 fdad8768
@PID: PyGate 1.5.18
@TID: PyGate/Linux 1.5.18
@NOTE: slrn/1.0.3 (Linux)
@CHRS: ASCII 1
@TZUTC: 0000
@REPLYADDR: spamtrap42@jacob21819.net
@REPLYTO: 3:633/10 UUCP
@RFC-Message-ID:
<slrn115bdjb.bvd.spamtrap42@one.localnet>
On 2026-07-13, Tom Blenko <
blenko@martingalesystems.com> wrote:
> In article <
slrn115a3i3.ki8.spamtrap42@one.localnet>, Robert Riches
><
spamtrap42@jacob21819.net> wrote:
>
>> An analogous thing happens in SQL database design. Academics
>> preach normalization at an absolute goal. However, with a
>> sufficiently complex system, full normalization can require each
>> query to use an excessive number of joins, and that can adversely
>> affect performance. Those with practical experience in DB design
>> will concede that sometimes you need to denormalize slightly in
>> order to get reasonable performance.
>
> This is nonsense and a good hint is that you are putting words in the
> mouths of others and then attacking them for those words.
>
> I`ve never taken a database course but I had nearly 20 years of
> database design in industry for mid-level systems. I have read some
> database books written by academics along the way. The claim that they
> "preach normalization at (sic) an absolute goal" is plain wrong in my
> experience.
Yes, you caught my typo.
It appears your experience differs from mine. Evidently, the
academics who wrote the books you read had a different take from
the professors who taught my DB courses at Oregon Graduate
Institute in 2001 and those who wrote the articles I studied with
colleagues around 2024-2025. I`m glad you had the good fortune
in your study and practical experience to see and adopt a more
balanced approach.
> The academic books I`ve read describe multiple normal forms. I don`t
> recall ever seeing one singled as superior to all the others, different
> normal forms reflect different (generally theoretical) perspectives on
> data and the relational calculus. Not surprising, I think, and I am
> confident that being informed about different perspectives has helped
> me design systems.
>
> Database design requires a designer to balance various factors,
> including where the data comes from, how it is to be maintained, and
> how it is to be used (including performance of queries). I have no idea
> which of all the tables I`ve designed and run in production may or may
> not be normalized by any of the multiple normalizations that have been
> described. But I read those books in order to improve my skills and it
> was time well spent.
>
> Tom
Thank you for describing your experience and perspective.
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
--- PyGate Linux v1.5.18
* Origin: Dragon`s Lair, PyGate NNTP<>Fido Gate (3:633/10)
SEEN-BY: 19/10 50/109 153/757 218/840 840 220/70
221/1 6 360 226/17 100
SEEN-BY: 229/426 240/1120 267/800 301/1 113 812
310/31 335/364 341/66 463/68
SEEN-BY: 633/10 20 280 281 414 416 418 420 422
509 2744 712/848 770/1 3 100
SEEN-BY: 770/340 350 772/210 220 230 5019/40
5020/715 848 1042 4441 12000
SEEN-BY: 5030/49 722 1081 1474 5053/55 5061/133
5075/128
@PATH: 633/10 280 770/1 218/840 221/6 301/1
5020/1042 4441