Re: Keys larger than 2 Billion
From informix-list-owner@rmy.emory.edu Sat Sep 14 11:28:57 1996 Received: from rmy.rmy.emory.edu by hobbes.dbintellect.com via ESMTP (940816.SGI.8.6.9/930416.SGI.AUTO) for <settler@dbintellect.com> id LAA25389; Sat, 14 Sep 1996 11:28:56 -0600 Received: (from ilist@localhost) by rmy.rmy.emory.edu (8.7.1/8.7.1) id NAA02383 for settler@dbintellect.com; Sat, 14 Sep 1996 13:29:23 -0400 (EDT) From: Nils.Myklebust@idg.no (Nils Myklebust) Message-Id: <51ejl0$14q@nic.global-one.no> Subject: Re: Keys larger than 2 Billion Date: Sat, 14 Sep 1996 15:47:32 GMT Reply-To: Nils.Myklebust@idg.no (Nils Myklebust) Organization: NM Data AS Sender: informix-list-owner@rmy.emory.edu To: informix-list@rmy.emory.edu X-Informix-List-To: settler@dbintellect.com X-Informix-List-Id: <news.28079> It would be interesting to here a little about the application. This would mean 1 row inserted every second for 63 years or 10 rows a second for over 6 years - day and night. Interesting. For a project like this you should be able to make Informix extend their XPS engine with a serial datatype with 64 bit integers. Frank Dickinson <frdi@gate.net> 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. :Does anyone have any input on this? Has anyone seen anything :like this done? I am sure that there are probably a hundred :ways to do this, I am looking for a good discussion of the pros :and cons of different approaches. :Any help would be appreciated. :Thanks, :Frank Dickinson (frdi@gate.net) :====================================================== :Metal forged of the hottest flame is strongest! :====================================================== Nils.Myklebust@idg.no <- New E-mail adress NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company We plan to store several years of point-of-sale system transactions, so we will definitely hit the upper limit using a SERIAL datatype as a key. I don't have a brilliant solution to this problem -- yet. ------------------------------------------------------------------- Jeff Craig | dbINTELLECT Technologies, Inc. Senior Consultant | Golden, CO | (303) 275-6954 ext. 8008 | email: settler@dbintellect.com | fax: (303) 275-2134 -------------------------------------------------------------------