Being a newbie to database design, I wonder if those more experienced could
give me an opinion on what constitutes "good practice" - as opposed to what
is technically possible. I know what I want to do is technically possible,
but am I lining mself up for trouble by doing it?

I know that it is a good database design never to have a particular datum
more than once in the database, and to construct views of the database
using Joins. I interpret this as a general invocation against redundancy.
However, I want to used some redundancy within a row, and wonder if this is
regarded as a bad idea.

I have three data: start, finish, and length, and I may want to search by
different combinations of them Obviously, these are redundant:
length=finish - start. If I choose to store start and finish, I can obtain
them in (say) length order by doing
     SELECT (finish-start) AS length from table ORDER BY length ;
and obviously I an do the reverse calculation if I choose to store start
and length.

However, this involves MySQL in doing significant calculations as part of
the search. Searches will obviously be faster if it doesn't have any
calculations to do - I can even index by length, making the searches much
faster again. But I don't have any feel for how much faster. I can easily
afford the disk space for the extra column.

Things that make the redundancy less dangerous are:
     All inserts will be done by one application (well, today) and can
therefore be funnelled through one routine
     There are no updates (again, as of today)

Is this a reasonable thing to do, or a bad idea?

Thanks in advance of any opinions.

     Alec Cawley

<<--
This e-mail is intended for the named addressees only.  Its contents may be
privileged or confidential and should be treated as such.  If you are not
an intended recipient please notify the sender immediately; do not copy,
distribute, or take any action based on this e-mail; and then delete it.
In the pursuit of its legitimate business activities and its conformance
with relevant legislation, Quantel Ltd. may access any e-mail (including
attachments) it originates and receives, for potential scrutiny.

Version 10 of the Quantel Digital Factbook is now online -
http://www.quantel.com/dfb


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to