SQL Database

[Cap'n Refsmmat]

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.

[john5746]

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.

[Klaynos]

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

[doG]

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.

[Chuck Edge]

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.