Re: Keys larger than 2 Billion

settler@hobbes.dbintellect.com (Jeff Craig) wrote: :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. Have you thought of not having a primary key at all? I assume this is some kind of a datawarehouse where data from all the stores are stored, and you talk about the primary data table (the fact table in a star/snowflake schema perhaps?). You obviously need a primary key to update individual records, but will you ever do that? For all other purposes isn't it enough with regular indexes on the different fields? You obviously need to find data relating to a spesific store, time periode, product/product group and so on, but can't all that be done without a primary key? Some will cringe at the idea of not having a primary key on a table, but if we are talking about a datawarehouse you will probably do all kinds of denormalization and other things that are equally "bad" from such a point of view. If you do need a unique key your own suggestion about a "time" field in addition to an integer might be fine. I assume you load all this data from different sources via some special load-program. Isn't it an idea to add these fields during the load, before data is inserted into the database and make sure they are unique at this time? You will (probably) have to use the XPS engine to store and access all this data, and my opinion is still that you should talk to Informix about an extended serial datatype if you realy need it. May be they allready have it, or at least will be willing to implement one. 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