|
|
Posted by BearItAll on 10/10/41 11:34
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.
Navigation:
[Reply to this message]
|