By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,960 Members | 2,246 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,960 IT Pros & Developers. It's quick & easy.

How should I create a new DB that uses a customer table from an existing DB?

P: 256
I have an existing DB that has a customer table with all sorts of handy information. There are a lot of other tables but it's this customer table in particular that this post is about.

I want to make another DB, but the customers for the new DB will include many of the same customers in the existing DB. To make more sense, I'll give more details. The first, existing, and well-functioning database is used to test rubber gloves for a utility. The second database will be to test rubber blankets for the same utility. 80% of the customers get both gloves AND blankets. 10% get just gloves. 10% get just blankets. The contact information for the customers changes frequently so it makes a lot of sense to have just one table so we aren't having to make changes in two tables. I thought maybe we could have a True/False field for gloves and a True/False field for blankets. When you open the glove program it would only show customers true for gloves, and likewise for blankets.

My question is:
Should I remove the table completely from the first (glove) database and have both databases link to the table? Or should I leave it in the glove DB and link blanket DB to it? I have read a bit about front end and back end but it seems this always talks about having "all" the tables on the back end. I want to do whatever is simplest. My knowledge is limited (but I'm not scared to learn something new).

I'm just looking for good advice. Any takers?? :-)
May 21 '12 #1

✓ answered by Rabbit

I suspect there will be enourmous overlap between the two databases. Why create two databases when you can just add to the existing one?

Share this Question
Share on Google+
5 Replies

Expert Mod 10K+
P: 12,366
I suspect there will be enourmous overlap between the two databases. Why create two databases when you can just add to the existing one?
May 21 '12 #2

P: 256
Glove customers are tested every 90 days. Blanket customers are tested every 365 days. One customer does not get both at the same time. The lab works on gloves one week, and blankets one week. While there are some similarities, they don't even pull reports for gloves and blankets on the same day.
With that said, I suppose I COULD use one DB and have a start up screen that makes them select gloves or blankets. But then they couldn't run both concurrently unless they closed out of the other. Maybe my mind isn't open enough about this. I always listen to those smarter than me. Given this information, would you still use one DB?
I guess the short answer to your question is that I thought 2DBs would be simpler, and easier to manage. I'm still an elementary user, and would like to keep reports, queries, etc., separated for my own benefit when maintaining the systems. The glove program is already pretty complex. (Success largely due to your counterpart NeoPa.) :-) Advice appreciated.
May 21 '12 #3

Expert Mod 10K+
P: 12,366
I don't know the intricacies of your business requirements. But in the end, it doesn't really matter whether they get tested on both at the same time or how often they get tested or when they pull the reports. What matters is how similar the data and structure is between the two functions. While two databases may be simpler in that everything is siloed and makes it easier to comprehend, it's more complex in terms of maintenance. If the structure is very similar, then any change made in one database probably have to be replicated to the other database.

If the structure is significantly different, then yes, a new database may be a good idea. But I can't determine whether or not that is the case.

I'm not sure why they would need to run the databases concurrently, because you said they never overlap. So there would never be a need to have concurrency. However, no one said you can't have "concurrency" in a single database. Just open both forms at the same time. Then it's just a matter of switching between two open forms instead of two open databases.
May 21 '12 #4

Expert Mod 15k+
P: 31,492
Hi Danica. I hope you're all better now.

As you can probably tell, Rabbit's advice is spot on here. I would think it's almost certain that designing the single database to handle multiple functions is the way to go.

Feel free to call me about it if you're unsure about any of it. I can explain why one approach would make more sense from a database designer / maintainer point of view than the other.
May 22 '12 #5

P: 256
Ok, I will carry on in this manner. Thanks everyone!!
May 22 '12 #6

Post your reply

Sign in to post your reply or Sign up for a free account.