Re: Keys larger than 2 Billion

Frank based on the information you supplied using serial key with a time stamp value is an excellent approach for key value. Not only will it not hold a lot of Index space in the DB, but it will also make the Archival process easy, if you later want to remove older data. Since, from the way the table is presently designed this is how data is being stored. Try creating a UNIQUE index on the actual data being inserted into this table to remove the redundancy of data. Yet, sometimes with older data and DB's this is not an easy thing to do. Notice I brought in the discussion of Archive, this is because with this type of KEY on a table your DB table will continually grow over time. Therefore, you should also address Archiving of DATA from this table in using that approach. ------------------------------------------------------------------------- Cheryl Kendricks Internet:cherylk@prod1.jcdc.doleta.gov OR cherylk@gwysmtp.jcdc.doleta.gov DTSI, Inc. Database Administrator - DOL Job Corps San Marcos, Texas ------------------------------------------------------------------------ On Sat, 14 Sep 1996, Frank Dickinson wrote: > We have an application where we want to plan for some of our > tables to have more than 2 billion rows. Currently we have a > primary key that is a SERIAL type column, but this will only > handle unique IDs up to 2 billion rows. We have thought about > having a composite primary key with the first value being a > julian day or some kind of month and a second column that is > serial. Another idea is to handle incrementing ourselves by > storing a current value in some control table, but this will add > more overhead to an insert........... [SNIP] > > Any help would be appreciated. > > Thanks, > Frank Dickinson (frdi@gate.net)