Adriaan Joubert wrote:
> Yep. Also, you fix one set of hard links and the next day you need to do
> a slightly different join and it doesn't fit into the links you
> constructed, because you left out a table or something silly.
>
No one is talking about abolishing any standard SQL feature. After
you carefully verified design you can hard-code links to speedup
access. Before that has happened the usual SQL will do.
> Leon, I think you should study the accesses, and build the right
> intermediate tables. Yes, I know you are not supposed to duplicate data,
> but hey, this is the real world, and disk is cheap.
But RAM is not as big as HDD. If database doesn't fit in RAM performance
degrades severely.
> And triggers etc
> make it fairly managable to retain integrity.
Making trigger would cost the same as rearranging the table after
poor design of links is discovered.
> But what is indispensable
> is the flexibility you have in a true relational model, so that you can
> easily adapt to changing demands -- adding temporary tables as you need
> them for new reports and dropping them as they go out of use.
This will immensely bloat the database thus flooding the disk
channel and, what is worse, the main memory.
--
Leon.