On 7/7/06, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
On Thu, Jul 06, 2006 at 05:18:16PM -0400, D'Arcy J.M. Cain wrote:
> owns/resides there in a situation where the address can never be
> changed, e.g. "521 Main" splitting into "521A Main" and "521B Main."
And anyone who has looked at an even m
On Fri, 2006-07-07 at 03:07, David Clarke wrote:
> Yep, this was pretty much where I started from and I totally agree
> with you regarding premature optimisation. I would point out that md5
> hash is 128 bits or 16 bytes and not 32
Unless you're going to store them as a binary field, the standar
darcy@druid.net ("D'Arcy J.M. Cain") writes:
> 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 "re
Hi D'Arcy,
> It's not that I think that the primary key should never have
> meaning in the database (I use the two letter country code as
> the PK in my country table for example) I just think that
> it's dangerous ground and should be tread very carefully.
You are right. I now realize that I
Andrew Sullivan wrote:
On Thu, Jul 06, 2006 at 05:18:16PM -0400, D'Arcy J.M. Cain wrote:
owns/resides there in a situation where the address can never be
changed, e.g. "521 Main" splitting into "521A Main" and "521B Main."
And anyone who has looked at an even moderately old city map will
tell
O D'Arcy J.M. Cain έγραψε στις Jul 7, 2006 :
> On Fri, 7 Jul 2006 19:37:15 +1200
> "David Clarke" <[EMAIL PROTECTED]> wrote:
> > > And even given all of that, I would probably still use serial.
> > Because?
>
> Simplicity. Cleanliness.
>
> > > Danger, Will Robinson. The phrase "regenerate my p
On Fri, 7 Jul 2006 19:37:15 +1200
"David Clarke" <[EMAIL PROTECTED]> wrote:
> > And even given all of that, I would probably still use serial.
> Because?
Simplicity. Cleanliness.
> > Danger, Will Robinson. The phrase "regenerate my primary key"
> > immediately raises the hairs on the back of my
On Thu, Jul 06, 2006 at 05:18:16PM -0400, D'Arcy J.M. Cain wrote:
> owns/resides there in a situation where the address can never be
> changed, e.g. "521 Main" splitting into "521A Main" and "521B Main."
And anyone who has looked at an even moderately old city map will
tell you that even this "imp
On Thu, Jul 06, 2006 at 09:41:52AM -0500, Scott Marlowe wrote:
> Please note that there seemed to be a misunderstanding in a few
> responses that this gentleman had 100 columns to key.
Oh, yes, that wa certainly my understanding. I totally agree that
this is premature optimisation then.
A
-
On 7/7/06, David Clarke <[EMAIL PROTECTED]> wrote:
The question remains regarding the use of a string value as a primarykey for the table and as a foreign key in other tables. If I use theaddress column as a foreign key in a differrent table will postgresphysically duplicate the data or will it sim
On 7/7/06, Scott Marlowe <[EMAIL PROTECTED]> wrote:
On Thu, 2006-07-06 at 16:43, Aaron Bono wrote:
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
On 7/7/06, D'Arcy J.M. Cain wrote:
Are you sure? I have a hard time imagining a situation where that
Absolutely.
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."
Actually that
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 e
> 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 t
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
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 k
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 sear
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 has
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) m
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
pr
> 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
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 fo
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 colum
[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
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 va
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.
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
genera
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,
>
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
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 b
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 dat
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
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). P
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 th
34 matches
Mail list logo
