damageinc86
Registered User.
- Local time
- Today, 15:29
- Joined
- Dec 18, 2016
- Messages
- 24
I am trying to setup a database for my desk at work which will eventually have thousands and thousands of customer numbers, with details about each customer. Each customer number will have a bunch of details like dates and document numbers and such, each needing their own row for one date's worth of info. So I was wondering which way would be more efficient to store this:
A. One table with all customer numbers (primary key), and a table for each customer with all the details within (relationship I assume?).
Or B. One huge table with duplicate customer number entries for each row of data needed.
I started out using the second method with only a few customer numbers and only a few rows of dates entered. I have successfully setup a query form that will run the filter query in a subform based on what customer number you type in. It shows each row with that customer number, along with all that info. But what I'm worried about is having an incredibly huge table with so many duplicate customer numbers each with their own row, and just having it be too much all in one place.
If I go the table route, then each customer will have their own table named after their customer number, which obviously would mean thousands of tables. I don't know if that's bad practice? But I was thinking that the main table with just customer ID#'s could call upon whichever table matched that customer ID and show the records from that table in a subform. I couldn't figure that out on my own at all by using relationships, so I gave up.
any ideas on how to set this up?
A. One table with all customer numbers (primary key), and a table for each customer with all the details within (relationship I assume?).
Or B. One huge table with duplicate customer number entries for each row of data needed.
I started out using the second method with only a few customer numbers and only a few rows of dates entered. I have successfully setup a query form that will run the filter query in a subform based on what customer number you type in. It shows each row with that customer number, along with all that info. But what I'm worried about is having an incredibly huge table with so many duplicate customer numbers each with their own row, and just having it be too much all in one place.
If I go the table route, then each customer will have their own table named after their customer number, which obviously would mean thousands of tables. I don't know if that's bad practice? But I was thinking that the main table with just customer ID#'s could call upon whichever table matched that customer ID and show the records from that table in a subform. I couldn't figure that out on my own at all by using relationships, so I gave up.
any ideas on how to set this up?