Cap'n Refsmmat Posted July 13, 2006 Share Posted July 13, 2006 I'm still not sure of everything the program will need to do. However, I think it will have to do much more than one task. You need to find out exactly what its requirements are before you can start making databases and such. You may end up realizing that you have to completely redo something because of a requirement you didn't know about yet. Link to comment Share on other sites More sharing options...
john5746 Posted July 13, 2006 Share Posted July 13, 2006 From what I've heard today' date=' the company wants to separate the data into two separate databases. A new database will be managed through the program I need to create. This database will contain all the customer information for people who automatically renew their account. The other database will contain the rest of the customers. The old database will be managed using the program they already have. The reason for them splitting up the data is because the old program doesn't let them sort certain information related to renewing accounts. I'm still not really sure of everything the program will need to do. The company just gave me a little information about what they need, and they want to know if I can create the program, or if they will need to hire a programmer to complete the task.[/quote'] Well, I don't know all the details, but they should seperate the data from the tasks. One database, with a field indicating an automatic renewed account would be better than two seperate databases. What if an existing customer changes status? Would then need to delete out of one and add to the other. Just keep the data in one DB and have two seperate applications if needed. If they are going to make decisions like this without any input from you, tell them to farm it out to someone else. Link to comment Share on other sites More sharing options...
Klaynos Posted July 13, 2006 Share Posted July 13, 2006 duplication of data is nearly always a bad thing. And just think of the time you can save just adding in functionality instead of having to duplicate all the functionality and then add the new stuff.... And I would seriousely advise avoiding Access, I've seen it crash and burn too many times SQL Server is alright though Link to comment Share on other sites More sharing options...
doG Posted July 13, 2006 Share Posted July 13, 2006 From what I've heard today' date=' the company wants to separate the data into two separate databases. A new database will be managed through the program I need to create. This database will contain all the customer information for people who automatically renew their account. The other database will contain the rest of the customers. The old database will be managed using the program they already have. The reason for them splitting up the data is because the old program doesn't let them sort certain information related to renewing accounts......[/quote'] Bad idea. Keep the data in one place. Add tables and/or columns to manage the data associated with renewed customers. There will be other business reports a company needs on all of the customers and you don't want tables like your customer table split into two databases. Link to comment Share on other sites More sharing options...
Chuck Edge Posted July 13, 2006 Share Posted July 13, 2006 I just checked, and the database is a Microsoft SQL server. Excellent. Dog's on the right track, but some quick questions. When you say the company wants to "separate the data into two separate database," are you talking about mirroring or actually splitting data? Basically Dog is assuming that data shared between the two DBs evolves in lock stop. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now