Bobadopolis
No I can't fix it dammit!
- Local time
- Today, 09:59
- Joined
- Oct 6, 2005
- Messages
- 77
Hi People,
I am building a database of in-car audio systems. Stored in this are simple things like vehicle information, audio brand and other general information. The main information I need to store includes details about speakers (position, quantity, material, range, size etc.) and amplifiers (power output, no. of channels etc.). Sounds simple I hope.
I have been thinking about this extensively and have come up with two solutions, each with its own pros and cons. My primary concern here is how the speaker and amplifier information is stored:
1) Tables specific to car regions (e.g. Rear Speakers, Front Speaker, Surround Speakers) have the fields 'Range', 'Material', Size, etc. Range and material can read their values from other look-up tables no probs. These would be linked to the main table via it's primary key in a 1-M relationship.
-Pros:
Ease of construction and general handling of data
Flexibilty/expandability (in terms of speaker quantity)
-Cons:
When it comes to data entry the form would need to be continuous and continuous forms I have found to be a pain in terms of referring to individual records!
I want some of these controls to conrol a diagram for my report (and input form) - such that they show/hide speaker pictures on a car diagram. Also, I have not yet figured out how to validate a continuous form in this situation or delete records from it either (should the user makes an error).
2) Again, tables specific to car regions but this time with a field for each speaker range (mid-range, tweeter, woofer, etc.) and it's associated data, tied to the main table via the main table ID in 1:M relationships.
-Pros:
Easy to manipulate form/report properties because every speaker has its own field
Easier to remove erroneous data (I imagine)
-Cons:
More complex construction (and less efficient) - e.g. material occurs more than once for each record so to look up material form a central pool requires an intermediate table
Many many more fields!
Non-expandable in terms of speaker quantity
Similar principals can be applied to amplifiers so I haven't mentioned those.
So what do you think? Or is there another way...
Hope that all makes sense!
Thanks for your time,
Bobadopolis
I am building a database of in-car audio systems. Stored in this are simple things like vehicle information, audio brand and other general information. The main information I need to store includes details about speakers (position, quantity, material, range, size etc.) and amplifiers (power output, no. of channels etc.). Sounds simple I hope.
I have been thinking about this extensively and have come up with two solutions, each with its own pros and cons. My primary concern here is how the speaker and amplifier information is stored:
1) Tables specific to car regions (e.g. Rear Speakers, Front Speaker, Surround Speakers) have the fields 'Range', 'Material', Size, etc. Range and material can read their values from other look-up tables no probs. These would be linked to the main table via it's primary key in a 1-M relationship.
-Pros:
Ease of construction and general handling of data
Flexibilty/expandability (in terms of speaker quantity)
-Cons:
When it comes to data entry the form would need to be continuous and continuous forms I have found to be a pain in terms of referring to individual records!
I want some of these controls to conrol a diagram for my report (and input form) - such that they show/hide speaker pictures on a car diagram. Also, I have not yet figured out how to validate a continuous form in this situation or delete records from it either (should the user makes an error).
2) Again, tables specific to car regions but this time with a field for each speaker range (mid-range, tweeter, woofer, etc.) and it's associated data, tied to the main table via the main table ID in 1:M relationships.
-Pros:
Easy to manipulate form/report properties because every speaker has its own field
Easier to remove erroneous data (I imagine)
-Cons:
More complex construction (and less efficient) - e.g. material occurs more than once for each record so to look up material form a central pool requires an intermediate table
Many many more fields!
Non-expandable in terms of speaker quantity
Similar principals can be applied to amplifiers so I haven't mentioned those.
So what do you think? Or is there another way...
Hope that all makes sense!
Thanks for your time,
Bobadopolis