Posted by Ian Hobson on 12/11/05 22:25

In message <54cjp15t2ssi61mkir24gmli08mhg4g9fm@4ax.com>, cover
<coverlandNOSPAM914@yahoo.com> writes
>I have two distinctively different pieces of equipment that I'm trying
>to build a database for, each having 20 inputs which makes my mysql
>table 40 fields wide.
>
[Snip]

a) First step is to ignore for now that you are using any particular
database, and simply look at the data. Create a list of the real world
things you have to record information about, and, against each, list the
single value properties that you must record.

Then add any events that can happen, that you are interested in, and the
information (again, single values) you need to keep about those events.

I expect these are motors, conveyors and shakers, and perhaps repairs,
sales, modifications, tests, etc.

b) Normalise the data. This means remove *ALL* duplication and
repetition.

There is a single logical place for everything, and everything has
exactly one logical place that it could go.

Any conceivable change to a data value, involves just a SINGLE data
field changing. e.g. If a motor's max operating temp changes, it must be
changed in the data you store about a type of motor, not with the data
about the motor's use, repair, purchase, test log etc. Neither should
max operating temp be stored with the conveyor table against the motor
you are using.

Although blank fields are permitted, you will find they usually mean you
are missing data. If not, treat this as a warning that you have it
wrong.

Repetition involves creating another table in almost all cases. You CAN
avoid it if the repetition is always exactly some small number, and you
know this will have to be true for all future objects of this type, even
those that have not yet been designed, thought up, or conceived of yet.
Even then you are taking a risk. Remember in the database you are trying
to record the real world as it is in all its variety. Validation is for
the programming, not the database!

c) Now you create your database design. Objects and Events map to
tables. Properties become fields. If you have any difficulty with this,
go and do step b properly!

d) Build the system. Test it. Stress test it. Is it fast enough? It
probably will be.

e) If, and only if, some operations you need to do are not fast enough,
the next step is to instrument your code and discover where, exactly the
bottle neck is. Until you now exactly what is taking the time, and why,
all you have as a guess. Such guesses are near useless even with a lot
of experience.

f) If you have proved the problem is in the database, you may consider
your options. Some ideas

1) Spend $150 throwing memory at the problem.
2) Spend $400 throwing a fast SCSI disk at the problem.
3) Consider how the slow operation is performed, and approach it in
another way. This may be as simple as doing a sub operation against
every row in a table to fool the optimiser into doing the job
efficiently. In the worst case I know of, it involved creating a
temporary table that was then processed in a new order, and discarded
when the job was complete. Cost - a week or two without one program -
say $3000.
4) Spend a month ($10000?) working out how to change the tables, and
where to update multiple fields, to de-normalise the data, and making
the changes, and then another $10000 sorting out the bugs you just
created. Ask your manager to estimate the opportunity cost of being 2
months late, and factor that cost in also, before you go this route.

Hardware is cheap and getting cheaper. People are expensive and getting
more costly. You are trying to make things hardware efficient to save a
few milliseconds. What you will achieve is making things confusing for
people and that will cost a lot in delay and future maintenance costs.

Regards

Ian

--
Ian - posting to a Newsgroup. Please remove everything to reply.

[Back to original message]