HELP WITH DATA MODELING P

7> From: Atul Varde <72712.341@compuserve.com> 7> In your experience, how much difference does it make in terms of > performance, if the data types of fields used in joins are characters, as > opposed to numbers? If we added serial/integer fields to be the > primary/foreign keys respectively in this application, would that be > worth a 4 day effort to implement the change? If you are beyond the business design (which I assume you are) then you probably know what the anticipated usage of this database is. That is an important piece in your decision. How big are the tables (# of rows, width of rows). Is data accessed typically in single rows, small batches or large batches? What is the frequency and concurrancy of these accesses? I am working on a project where our "backbone" is a char (12) primary key in a table with 100,000 rows, though other tables may have several hundred thousand rows, we have not seen the char (12) as an access issue. On the corporate side of our project, we will have a table that will have 175 million rows, but we haven't looked at the char (12) / integer issue. Due to the type of data on that table, however, it doesn't look like an integer would be feasible from a maintenance point-of-view. That is because every day or week we would be adding about 1.5% new rows and dropping an equivalent number of old rows. There are other issues as well, like timing. I would tend to say stick with your key, but maybe your backbone is more stable and there would be less of a maintenance issue. Unless you are going to be doing some heavy queries, you probably wouldn't notice a big difference in response. One way you can test is to build an identical database replacing the char (26) keys with integers, populating the same datasets in both databases and run a few sql select statements through both. Tim --- ~ SPEED 1.40 [NR] ~