Database & DB Size Question

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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

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

thanks for any advice,


Re: Database & DB Size Question

Quoted text here. Click to load it

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  

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  

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.



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

Re: Database & DB Size Question

On Sun, 11 Dec 2005 20:25:30 GMT, Ian Hobson

Quoted text here. Click to load it
Thanks Ian - appreciate your help very much.

Re: Database & DB Size Question

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

Quoted text here. Click to load it

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.

Re: Database & DB Size Question

Site Timeline