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, [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 nextva
> 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 i
> 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 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(we
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
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
26 matches
Mail list logo
