
July 28th, 2004, 12:34 PM
|
|
Contributing User
|
|
Join Date: Jul 2004
Location: Atlanta, GA
Posts: 118
  
Time spent in forums: 22 h 30 m 37 sec
Reputation Power: 9
|
|
Quote: | Originally Posted by zirtbow So where I work is thinking about one day moving to SQL server. Right now they have indexed files that aren't normalized with repeating fields in them and lots of repeat data and blank space (so a customer number in one file may be stored literally in 10 other files that are easily realted). In the intrest of saving time and money I think that they will not normalize, index, or anything to any of these files. From what I hear it will be a straight field by field creation for the most part and preserving the primary keys.
My question: I keep thinking this is going to be massive hit on performance and maintaince. How much would converting in such a manner hurt the performance of their database and how much could it potentially add to maintaince? |
Performance hit is hard to say. Maintenance would be a nightmare, because if you change a field in one table, you might also have to change it in several other tables.
Normalizing would be ideal, but it depends on how the tables are accessed. Changing the table structures will require a programming change. If they are accessed via stored procedures, then you could do incremental changes. If there are convoluted SQL commands in the client programs, you will have a much harder sell because it will require development efforts, coordination, program update rollouts, etc.
|