Database & DB Size Question

[cover]

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.

Form one is for 'shakers' and form two is for 'conveyors'. About the
only thing they will have in common is that they both share
'motorsize' and they both share 'bearing' although shakers have two
where conveyors have four.

I'd first built a table within a database called 'equipment' just for
shakers and and planned on doing another one called 'conveyors' to
capture contents from the conveyor form.

The reason I'd thought about placing inputs from both forms into a
single table was for better queryability from a single query form
where I'd be sure to capture even common elements such as where all I
use a particular 'bearing' without having to query each table
separately.

I noticed immediately that inputting data from my 'shakers' form was
not successful after I'd set the table up with 40 fields to capture
activity from both forms which maybe I could correct by adding <input
type="hidden" name="whatever" value="0"> as appropriate to fill up the
additional 20 fields for each respective form but that might be an odd
way to do it, not to mention what the database size might look like
down the road.

So, should I run input data from two twenty input forms into a table
of 40 fields or will the size grow so quickly that I am fast to regret
it.

thanks for any advice,

Chris

[Ian Hobson]

In message <54********************************@4ax.com>, cover
<co****************@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.

[BearItAll]

On Fri, 09 Dec 2005 08:44:14 -0800, cover wrote:

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.

Form one is for 'shakers' and form two is for 'conveyors'. About the
only thing they will have in common is that they both share
'motorsize' and they both share 'bearing' although shakers have two
where conveyors have four.

I'd first built a table within a database called 'equipment' just for
shakers and and planned on doing another one called 'conveyors' to
capture contents from the conveyor form.

The reason I'd thought about placing inputs from both forms into a
single table was for better queryability from a single query form
where I'd be sure to capture even common elements such as where all I
use a particular 'bearing' without having to query each table
separately.

I noticed immediately that inputting data from my 'shakers' form was
not successful after I'd set the table up with 40 fields to capture
activity from both forms which maybe I could correct by adding <input
type="hidden" name="whatever" value="0"> as appropriate to fill up the
additional 20 fields for each respective form but that might be an odd
way to do it, not to mention what the database size might look like
down the road.

So, should I run input data from two twenty input forms into a table
of 40 fields or will the size grow so quickly that I am fast to regret
it.

thanks for any advice,

Chris

Ian Holison put it better than me, but basically if your fields are
growing towards the 20plus mark it is almost certain that you have the
table the wrong way round. In that the fields should be records. Chances
are if you have 40 fields then at some time they will be 41, so you have
to plough through every query/report/form that makes use of that table.

Don't worry about multi-table queries, the modern engines cope with these
very well.

The tricky part is deciding what information links the various parts of
the data, which is basically what Ian is describing to you. I don't do
contract programming any more, but when I did a typical 8 months contract
for a database application, the first two months tends to be concerned
with the data alone, making sure you know how the data is used, playing
with it on paper moving fields around, normalising it.

I even did one database where they gave me spreadsheets, many spread
sheets, with many thousands of records they had built up over many years,
fields stretching from 'A1' to something like 'DD1'. It turned out from a
quick play that a great deal of that data was static, that then became a
much reduced link table, with a couple of tables no more than 5 fields
each for the changeable data.

[Sean]

http://en.wikipedia.org/wiki/Database_normalization

[cover]

On Sun, 11 Dec 2005 20:25:30 GMT, Ian Hobson
<Ne*******@ntlworld.everything.com> wrote:

In message <54********************************@4ax.com>, cover
<co****************@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.

Thanks Ian - appreciate your help very much.