In my experience with 1000+ database, the need to do that type of workaround is due to to a less that optimal database design. I have never had to do that with a properly normalized database.Originally Posted by InLaNoche
In my experience with 1000+ database, the need to do that type of workaround is due to to a less that optimal database design. I have never had to do that with a properly normalized database.
Boyd Trimmell aka HiTechCoach
Microsoft Access MVP -2010-2015
Programming: Nine different ways to do it right, a thousand ways to do it wrong.
Binary--it's as easy as 1-10-11
Well, I have experience with 3+ database, all self taught, unfortunately.... Which is why I have been frequenting here. I really do appreciate all the feed back and assistance. It will not be a problem for me to create the fields for PortNumber and ModuleNumber, I was just curious if that would be a waste/inefficient/<insert other here>. I will do so and continue the testing. Right now the staff management part of the Database works great, this part is for my team.
One of the major things following the rules of database normalization does is educes data duplication. by having data entered in only a single place. It also dramatically reduces the number of fields that are a EMPTY.
This ha help: http://sbuweb.tcu.edu/bjones/20263/A...sDB_Design.pdf
and also: http://www.accessmvp.com/strive4peace/
Boyd Trimmell aka HiTechCoach
Microsoft Access MVP -2010-2015
Programming: Nine different ways to do it right, a thousand ways to do it wrong.
Binary--it's as easy as 1-10-11
There is only so much you can do with table design.
At some point you realise that table structure alone isn't enough.
Everything I've read in this thread points to you wanting a tree structure.
The structure you show in post #16 is a tree...
...and the best way of handling a tree is a treeview control.
Obviously a tv control isn't good for reporting... so you need to decide what kind of reporting you need...
Your output kinda has a relevance to the input.
the report will be a bit simpler that other views of the data. Really, the reports would be by Switch, which I can easily pull from this (working from End points only). What I would need is a lookup feature, which would display the 'tree view'. I think I am also able to handle that, now that I have a better handle on storing the data. You all have been a tremendous help with this. So far I am able to store the data in a manageable way, without having 60+ fields that may never be used (cut that down to 3 fields that will be used for the switches, but I'm good with that).
I wish I could add more to your reputations, but they only let me pass out so much at a time (several of the posts here have been a great help).
Thanks!
Posting Permissions
Reply With Quote
