Re: [SQL] week ending
On 7/5/06, Keith Worthington <[EMAIL PROTECTED]> wrote: Hi All, I just finished writing a query that groups data based on the week number. SELECT EXTRACT(week FROM col_a) AS week_number, sum(col_b) AS col_b_total FROM foo WHERE foobar GROUP BY EXTRACT(week FROM col_a) ORDER BY EXTRACT(week FROM col_a); I would like to generate the starting date or ending date based on this number. IOW instead of telling the user "week number" which they won't understand I would like to provide either Friday's date for "week ending" or Monday's date for "week beginning". SELECT AS week_ending, sum(col_b) AS col_b_total FROM foo WHERE foobar GROUP BY EXTRACT(week FROM col_a) ORDER BY EXTRACT(week FROM col_a); -- Kind Regards, Keith select max(case when (to_char(col_a,'d') between 2 and 6) then col_a end) as week_ending, sum(col_b) as col_b_total from foo where foobar group by extract(year from col_a), extract(week from col_a) order by extract(year from col_a), extract(week from col_a); Regards, Rodrigo ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[SQL] Alternative to serial primary key
I posted a couple of weeks back a question regarding the use of a 100 char column as a primary key and the responses uniformily advised the use of a serial column. My concern is that the key is effectively abstract and I want to use the column as a foreign key in other tables. It occurred to me that if I used a hash function on insert to generate another column and used that column as the primary key then I have a value that meets a lot of the requirements for a good key, including that I can regenerate the exact value from my data, something that is impossible with a serial id. I also don't have to index the 100 char column in order to search on the table, I just need to calculate the hash value and check that against the calculated column. It does violate the rule that a table shouldn't contain a column that is calculated from another column in the table but I think it would still be more effective than a serial id. Is this a reasonable/normal thing to do? I know postgres contains an md5() hash function, is this likely to be fast enough to make this an effective choice? Are there other options? Am I just a noob barking up the wrong tree? It is getting kind of late and my brain is starting to hurt. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] Alternative to serial primary key
On Thu, Jul 06, 2006 at 10:16:42PM +1200, David Clarke wrote: > column that is calculated from another column in the table but I think > it would still be more effective than a serial id. There is the problem that the hash is not proved unique (in fact, someone has generated collisions on md5). Primary keys have to be unique, of course. I _think_ with a hundred columns, you could probably prove (using brute force, if need be) that the hashes are going to be unique, assuming the list of possible values in each column is bounded. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] Alternative to serial primary key
Hi, David, David Clarke wrote: > It occurred to me that if I used a hash function on insert to > generate another column and used that column as the primary key then I > have a value that meets a lot of the requirements for a good key, > including that I can regenerate the exact value from my data, > something that is impossible with a serial id. This is a good idea if you want to have taller indices, but you still need to re-check the "real" key due to hash collisions. It's some kind of lossy index, pretty the same as the GIST index type PostGIS uses. If you've plenty of time to spend, you could also bring the hash index type back to life, which is currently deprecated according to the PostgreSQL docs... HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Alternative to serial primary key
On 7/6/06, Markus Schaber <[EMAIL PROTECTED]> wrote: This is a good idea if you want to have taller indices, but you still need to re-check the "real" key due to hash collisions. I am aware there are collisions with md5 but without any actual proof I believe the risk to be very low with the data I'm storing which is a kind of scrubbed free form residential address. If you've plenty of time to spend, you could also bring the hash index type back to life, which is currently deprecated according to the PostgreSQL docs... Unfortunately with the meagre time I have available, the only dent I'm likely to make is in the wall with my head. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Alternative to serial primary key
Hi, David, David Clarke wrote: > On 7/6/06, Markus Schaber <[EMAIL PROTECTED]> wrote: >> This is a good idea if you want to have taller indices, but you still >> need to re-check the "real" key due to hash collisions. > > I am aware there are collisions with md5 but without any actual proof > I believe the risk to be very low with the data I'm storing which is a > kind of scrubbed free form residential address. Then you'll have to use the re-check approach, like: SELECT * FROM foo WHERE hashed_key = hash(mykey) && plain_key = mykey; And then have an non-unique index on hashed_key, and probably no index n my_key (to give the planner a hint which index to use). HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Alternative to serial primary key
On Thu, Jul 06, 2006 at 01:10:55PM +0200, Markus Schaber wrote: > Then you'll have to use the re-check approach, like: That sort of undermines the value of the calculated primary key, though, doesn't it? He'd need the unique index for FK references, which was the point, I thought. A -- Andrew Sullivan | [EMAIL PROTECTED] The whole tendency of modern prose is away from concreteness. --George Orwell ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Alternative to serial primary key
Hi, Andrew, Andrew Sullivan wrote: > On Thu, Jul 06, 2006 at 01:10:55PM +0200, Markus Schaber wrote: >> Then you'll have to use the re-check approach, like: > > That sort of undermines the value of the calculated primary key, > though, doesn't it? He'd need the unique index for FK references, > which was the point, I thought. Yes, risking collisions. It will work for some time, and then create a maintainance nightmare for his successors. :-) Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] Alternative to serial primary key
On 7/6/06, Andrew Sullivan <[EMAIL PROTECTED]> wrote: That sort of undermines the value of the calculated primary key, though, doesn't it? He'd need the unique index for FK references, which was the point, I thought. Yes, that occurred to me as well. Frankly I believe the md5 collision generation is more of a practical issue for crypto where for my purposes the potential for two residential street addresses to generate the same md5 hash value is effectively zero. And the md5 function is a builtin which I would hope is faster than anything I could write in pgsql. Could be wrong, I have been before. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Alternative to serial primary key
On Thu, Jul 06, 2006 at 01:28:58PM +0200, Markus Schaber wrote: > > Yes, risking collisions. It will work for some time, and then create a > maintainance nightmare for his successors. :-) Well, that plus you can't actually point a foreign key contraint at anything that isn't a unique contraint. A -- Andrew Sullivan | [EMAIL PROTECTED] "The year's penultimate month" is not in truth a good way of saying November. --H.W. Fowler ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Alternative to serial primary key
On Thu, Jul 06, 2006 at 11:32:36PM +1200, David Clarke wrote: > > Yes, that occurred to me as well. Frankly I believe the md5 collision > generation is more of a practical issue for crypto where for my > purposes the potential for two residential street addresses to > generate the same md5 hash value is effectively zero. And the md5 > function is a builtin which I would hope is faster than anything I > could write in pgsql. Could be wrong, I have been before. You could, of course, just put a unique index on it and accept that, in the event of collision, you'll have to cope with the error. It's probably an acceptable cheat, as you're right that the collision risk is pretty small. A -- Andrew Sullivan | [EMAIL PROTECTED] If they don't do anything, we don't need their acronym. --Josh Hamilton, on the US FEMA ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] Alternative to serial primary key
[EMAIL PROTECTED] (Andrew Sullivan) writes:
> On Thu, Jul 06, 2006 at 10:16:42PM +1200, David Clarke wrote:
>> column that is calculated from another column in the table but I think
>> it would still be more effective than a serial id.
>
> There is the problem that the hash is not proved unique (in fact,
> someone has generated collisions on md5). Primary keys have to be
> unique, of course.
>
> I _think_ with a hundred columns, you could probably prove (using
> brute force, if need be) that the hashes are going to be unique,
> assuming the list of possible values in each column is bounded.
Seems to me that would only happen if those hundred columns consisted
of values that could be fully enumerated before designing the hash.
In effect, if you know that each column selects from a predetermined
set of values that will never change, then you may assign a number to
each value, and then generate a function which amounts to...
hash := 0
for column from 1 to 100 do
multiple := degree[column]
hash := (hash + enum[column,value[column]]) * multiple
done
where degree[column] is the number of possible values for the column,
value[column] is the value found in the column, and enum[column,VALUE]
selects the integer associated with that column.
Unfortunately, this approach to hashing breaks down if there is ever a
reason to add to the list of values that can be stored in a column.
For instance, country codes per ISO 3166-1 are no good as one of these
enumerated columns because the set of countries in the world changes
every so often.
You could allow for that change by, say, allowing for an extra 100
entries that would likely allow the country codes to change for 50
years.
But that's the "good news" part.
If some of the 100 fields contain peoples' names, that's not
particularly usefully enumerable :-(. New names come up all the time,
even if only because immigration officials transliterate names into
English in inconsistent ways... Back in the days when I was an
accountant, I did tax returns for three Lebanese brothers who came to
Canada and who all have slightly different surnames in English even
though they were the same in (I presume) Arabic.
It would be nice to have a suitable hash, but I'm not sure it's
attainable...
--
output = ("cbbrowne" "@" "ntlug.org")
http://cbbrowne.com/info/spreadsheets.html
Rules of the Evil Overlord #114. "I will never accept a challenge from
the hero."
Re: [SQL] Alternative to serial primary key
On Thu, 2006-07-06 at 05:16, David Clarke wrote: > I posted a couple of weeks back a question regarding the use of a 100 > char column as a primary key and the responses uniformily advised the > use of a serial column. My concern is that the key is effectively > abstract and I want to use the column as a foreign key in other > tables. It occurred to me that if I used a hash function on insert to > generate another column and used that column as the primary key then I > have a value that meets a lot of the requirements for a good key, > including that I can regenerate the exact value from my data, > something that is impossible with a serial id. I also don't have to > index the 100 char column in order to search on the table, I just need > to calculate the hash value and check that against the calculated > column. It does violate the rule that a table shouldn't contain a > column that is calculated from another column in the table but I think > it would still be more effective than a serial id. > > Is this a reasonable/normal thing to do? I know postgres contains an > md5() hash function, is this likely to be fast enough to make this an > effective choice? Are there other options? Am I just a noob barking up > the wrong tree? It is getting kind of late and my brain is starting to > hurt. I've read the responses, I'm starting a new answer thread because I think that this is "premature optimization". Please note that there seemed to be a misunderstanding in a few responses that this gentleman had 100 columns to key. According to this post it is one column, with 100 characters in it. My guess is that any test you come up with will find no gain in md5ing a 100 char column. 1,000 or 10,000 maybe. But not 100. And since it was intimated this is an address, I would assume it's a varchar(100) not a char(100) since there's no reason for it to be padded, so it will not always even be 100 characters long. I would imagine initing your database for the C (Ascii) locale would be a much bigger performance gain than any md5 hashing would. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] week ending
On 7/5/06, Keith Worthington <[EMAIL PROTECTED]> wrote:
Hi All,I just finished writing a query that groups data based on the week number.SELECT EXTRACT(week FROM col_a) AS week_number,sum(col_b) AS col_b_total FROM foo WHERE foobar GROUP BY EXTRACT(week FROM col_a)
ORDER BY EXTRACT(week FROM col_a);I would like to generate the starting date or ending date based on thisnumber. IOW instead of telling the user "week number" which they won'tunderstand I would like to provide either Friday's date for "week
ending" or Monday's date for "week beginning".SELECT AS week_ending,sum(col_b) AS col_b_total FROM foo WHERE foobar GROUP BY EXTRACT(week FROM col_a)
ORDER BY EXTRACT(week FROM col_a);Try this. It puts Saturday as the Friday before it and Sunday as the Firday after so if you want Saturday or Sunday to be on different weeks you will need to do a little tweaking but this should get you going.
SELECT date_trunc('day', col_a + (interval '1 day' * (5 - extract(dow from col_a AS week_ending, sum(col_b) AS col_b_totalFROM fooGROUP BY date_trunc('day', col_a + (interval '1 day' * (5 - extract(dow from col_a
Re: [SQL] Alternative to serial primary key
On 7/6/06, David Clarke <[EMAIL PROTECTED]> wrote: I posted a couple of weeks back a question regarding the use of a 100char column as a primary key and the responses uniformily advised theuse of a serial column. My concern is that the key is effectivelyabstract and I want to use the column as a foreign key in other tables. I have a simple question... why do you want to use the column as a foreign key in other tables? If you use the serial column then all you need is a simple join to get the 100 char column out in your query. If you need to make things simpler, just create a view that does the join for you. Either there is some requirement here that I am not aware of or it sounds like you may be trying to use a sledge hammer on a nail.-Aaron
Re: [SQL] Alternative to serial primary key
> On 7/6/06, David Clarke <[EMAIL PROTECTED]> wrote: > > > > I posted a couple of weeks back a question > regarding the use of a 100 > > char column as a primary key and the responses > uniformily advised the > > use of a serial column. My concern is that the key > is effectively > > abstract and I want to use the column as a foreign > key in other > > tables. > > > I have a simple question... why do you want to use > the column as a foreign > key in other tables? If you use the serial column > then all you need is a > simple join to get the 100 char column out in your > query. If you need to > make things simpler, just create a view that does > the join for you. > > Either there is some requirement here that I am not > aware of or it sounds > like you may be trying to use a sledge hammer on a > nail. > > -Aaron i agree. all my primary keys are abstract - even though some don't have to be. iow, i'm comfortable using serials as my primary key even when i don't absolutely need to. in any case, the primary key is typically used as a unique identifer *and that's it*. the uniqueness makes it ideal for another table to use it to link related data. it sounds like you want a unique identifier *plus something else*. i'd argue that the "plus something else" belongs in a separate column. imho, your database life will be much easier and more consistent. good luck. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Foreign Key: what value?
> Hi,
> How to know the value which I must set in the
> foreign key field?. I have two
> tables:
>
>
> CREATE TABLE AA (
> Id SERIAL PRIMARY KEY,
> data char(9)
> );
>
> CREATE TABLE BB (
> BB_Id integer REFERENCES AA(Id) NOT NULL,
> field char(5)
> );
>
>
>
>
> I insert a register on table AA,
>
>INSERT INTO AA (data) VALUES ('123456789');
>
>
> and then, I want to insert a related register in
> table BB, but I do not
> know how get the proper value to the Foreign key
> BB_Id. Note that a lot of
> client are inserting at the same time on the AA
> table, so I can not just
> get the greater value of AA.Id
>
> Maybe using transactions ?. Any tip, URI, ... will
> be welcome.
>
>INSERT INTO BB (BB_Id, field) VALUES
> (??,'12345');
>
i alsways make my foreign key column data type int4.
i'm not sure if i read that somewhere. anyone, please
feel free to chime in if this isn't good practice.
read up on currval, nextval and that whole section.
you can begin by getting the nextval, assigning it to
a variable, insert it into your primary table and then
insert it into your related table as a foreign key.
from what i understand, either way should be
bulletproof. the way i described is more code, but
some minds might not mind paying that price b/c they
like the process better.
good luck.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [SQL] Foreign Key: what value?
On 7/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: i alsways make my foreign key column data type int4.i'm not sure if i read that somewhere. anyone, please feel free to chime in if this isn't good practice.read up on currval, nextval and that whole section.you can begin by getting the nextval, assigning it toa variable, insert it into your primary table and then insert it into your related table as a foreign key.from what i understand, either way should bebulletproof. the way i described is more code, butsome minds might not mind paying that price b/c they like the process better.good luck.Bigserial's are simply bigint's with a sequence that does the nextval part for you. Your approach works but takes more coding on your part. I would recommend using bigserial so you cut some of the work out for yourself. -Aaron
Re: [SQL] Alternative to serial primary key
On 7/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: i agree. all my primary keys are abstract - even though some don't have to be. iow, i'm comfortable using serials as my primary key even when i don't absolutely need to. Yes I had in fact already created my table using a serial as the primary key but I've been reading Celko's SQL Programming Style and the use of a hash on the address column as the primary key (and for use in FK's) meets a number of the requirements for a good key. The address column itself is the natural primary key but it doesn't make for a good FK. Plus I feel I would be remiss in not exploring an alternative to the serial key. To recap, yes there is only a single column, yes it is varchar. I need to do a lookup on the address column which is unique and use it as a foreign key in other tables. Using a serial id would obviously work and has been recommended. But having a hash function over the address column as the primary key means I can always regenerate my primary key from the data which is impossible with a serial key. I believe the risk of collision using md5 is effectively zero on this data and I can put a unique index over it. I'm kind of new to sql so apologies if this is a naive approach. Thanks to all for responses. Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Alternative to serial primary key
On Fri, 7 Jul 2006 08:30:57 +1200 "David Clarke" <[EMAIL PROTECTED]> wrote: > Yes I had in fact already created my table using a serial as the > primary key but I've been reading Celko's SQL Programming Style and > the use of a hash on the address column as the primary key (and for > use in FK's) meets a number of the requirements for a good key. The > address column itself is the natural primary key but it doesn't make Are you sure? I have a hard time imagining a situation where that would be true. The only thing I can think of is some sort of municipality database tracking properties regardless of who currently owns/resides there in a situation where the address can never be changed, e.g. "521 Main" splitting into "521A Main" and "521B Main." Is that the situation here? Also, you need to get into a lot more coding to handle the fact that "521 Main Avenue" is the same address as "521 Main Av." and "521 Main Ave" and even "521 Main." And even given all of that, I would probably still use serial. > and has been recommended. But having a hash function over the address > column as the primary key means I can always regenerate my primary key Danger, Will Robinson. The phrase "regenerate my primary key" immediately raises the hairs on the back of my neck. If the primary key can ever change, you have a broken schema. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] Alternative to serial primary key
On 7/6/06, David Clarke <[EMAIL PROTECTED]> wrote: To recap, yes there is only a single column, yes it is varchar. I needto do a lookup on the address column which is unique and use it as aforeign key in other tables. Using a serial id would obviously work and has been recommended. But having a hash function over the addresscolumn as the primary key means I can always regenerate my primary keyfrom the data which is impossible with a serial key. I believe therisk of collision using md5 is effectively zero on this data and I can put a unique index over it.So if you have:addresses address_id bigserial (pk), addressperson person_id bigserial (pk), first_name, last_name, address_idyou can do something likeINSERT INTO person ( address_id)SELECT 'Joe', 'Blow', address_idFROM addressesWHERE addresses.address = ?; No regeneration of PK necessary. If you index addresses.address the insert should run quickly, right?-Aaron Bono
Re: [SQL] Alternative to serial primary key
Hi, But having a hash function over the address column as the primary key means I can always regenerate my primary key Warning: don't attach a meaning to a primary key, as it might change - Sander ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Alternative to serial primary key
On Thu, 2006-07-06 at 16:43, Aaron Bono wrote: > On 7/6/06, David Clarke <[EMAIL PROTECTED]> wrote: > To recap, yes there is only a single column, yes it is > varchar. I need > to do a lookup on the address column which is unique and use > it as a > foreign key in other tables. Using a serial id would obviously > work > and has been recommended. But having a hash function over the > address > column as the primary key means I can always regenerate my > primary key > from the data which is impossible with a serial key. I believe > the > risk of collision using md5 is effectively zero on this data > and I can > put a unique index over it. I'll repeat my previous statement that this is premature optimization, and the hash is kind the wrong direction. If you store an int and the 1 to 100 characters in a varchar, you'll have about 4 to 8 bytes for the int (6 I think, but it's been a while) plus 1 to 200 or possibly more for the characters in the address. If you use C local with ASCII encoding, you can get single byte. If you switch to an md5 hash, you'll need ~50 bytes (average address about 1/2 max length, just a guess) plus 32 bytes, plus the extra bytes to keep track of the length of the fields. The table now becomes wider itself, and the md5 is generally about as big as the address, or fairly close to it. And you've got the possibility of md5 collisions to deal with. I'd say just FK off of the address field. It's a natural key, fairly small (100 bytes ain't really that big) and your primary key never needs any kind of regenerating or anything, because it's already there. Just set it up with cascading updates and deletes in case you need to edit it in the future. The first rule of optimization: Don't ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] Alternative to serial primary key
On Thu, 2006-07-06 at 16:45, Sander Steffann wrote: > Hi, > > > But having a hash function over the address > > column as the primary key means I can always regenerate my primary key > > Warning: don't attach a meaning to a primary key, as it might change And as long as it has cascading updates and deletes it doesn't matter if it changes. As long as it doesn't change into something that collides. This is a religious topic, and there's advantages to both ways. But if the field is and always must be unique and non-null, then there's no reason to not use it as a primary key. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Alternative to serial primary key
> Plus I feel I would be remiss in not > exploring an > alternative to the serial key. why? it is a tried and true method. > I can always > regenerate my primary key > from the data which is impossible with a serial key. why on earth would you need to "regenerate" the primary key? it is used to link related data in different tables, not as some sort of meaningful piece of data all by itself. even if you wanted to "regenerate" the primary key, using a serial is still easier. under the hash scheme, you have know the *exact* address... including abbreviation, periods, etc... if you use a serial, you could query the table using SQL's LIKE clause and get all the serial results that match the string you entered. if you enter the *exact* address, you'll get a single result - unless that address is entered twice. you can avoid that possibility by making address a unique column. when you link tables together, you can visually one big table with all the linked data... and that's what you can get when you join the tables. if you know one column's information (or part of it using LIKE), you can return any desired result in the same row (LIKE might return more than one result). > I believe the > risk of collision using md5 is effectively zero on > this data and I can > put a unique index over it. why risk it? what if you are wrong? > I'm kind of new to sql so apologies if this is a > naive approach. > Thanks to all for responses. no worries. i'm learning a ton as time goes on, myself. i do think you are over thinking this issue a bit, though. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Alternative to serial primary key
On 7/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Plus I feel I would be remiss in not> exploring an > alternative to the serial key.why? it is a tried and true method.Actually, there are two reasons I think it good for someone new to SQL to explore this option. First of all, it is very educational. Secondly, it is the person who stands up and says, "I know everyone does it this way, but what if we did it that way?" who has a chance of discovering something new. For this particular topic however, using the serial is very easy and using a hash is not only error prone but much more difficult.It is good to see different philosophies about foreign keys though! -Aaron Bono
