On 2013-04-02, Joe Van Dyk wrote:
> On Tue, Apr 2, 2013 at 11:16 AM, Merlin Moncure wrote:
>> On Tue, Apr 2, 2013 at 10:34 AM, Joe Van Dyk wrote:
>> >
>> > I've been wishing for a smaller uuid type for a while.
>> > I've been using a unique text column with a default of
>> > random_characters(12
Natural keys are in user data space. Thus they are not guaranteed invariant
and therefore cannot serve as persistent identity.
Also natural keys have the considerable defect of being of different type and
arity per logical entity type. This means that very nice things like dynamic
relationsh
On 03/04/13 06:37, Merlin Moncure wrote:
> On Tue, Apr 2, 2013 at 2:01 PM, Samantha Atkins wrote:
>> Natural keys are in user data space. Thus they are not guaranteed invariant
>> and therefore cannot serve as persistent identity.
Can't find Samantha's original post. I agree but done right they
On Tue, Apr 2, 2013 at 11:16 AM, Merlin Moncure wrote:
> On Tue, Apr 2, 2013 at 10:34 AM, Joe Van Dyk wrote:
> > On Mon, Apr 1, 2013 at 1:11 PM, Tim Uckun wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Apr 2, 2013 at 8:35 AM, jesusthefrog
> >> wrote:
> >>>
> >>> On the topic of 'natural' versus 'synt
On Tue, Apr 2, 2013 at 2:01 PM, Samantha Atkins wrote:
> Natural keys are in user data space. Thus they are not guaranteed invariant
> and therefore cannot serve as persistent identity.
That is true, but irrelevant in most real world cases. Also, nothing
is keeping you from using an extra mark
On Tue, Apr 2, 2013 at 10:34 AM, Joe Van Dyk wrote:
> On Mon, Apr 1, 2013 at 1:11 PM, Tim Uckun wrote:
>>
>>
>>
>>
>> On Tue, Apr 2, 2013 at 8:35 AM, jesusthefrog
>> wrote:
>>>
>>> On the topic of 'natural' versus 'synthetic' primary keys, I am generally
>>> in the camp that an extra ID field wo
On Mon, Apr 1, 2013 at 1:11 PM, Tim Uckun wrote:
>
>
>
> On Tue, Apr 2, 2013 at 8:35 AM, jesusthefrog wrote:
>
>> On the topic of 'natural' versus 'synthetic' primary keys, I am generally
>> in the camp that an extra ID field won't cost you too much, and while one
>> may not need it for a simple
On 02/04/13 08:35, jesusthefrog wrote:
On the topic of 'natural' versus 'synthetic' primary keys, I am
generally in the camp that an extra ID field won't cost you too much,
and while one may not need it for a simple table (i.e. id, name) one
might add any number of columns later, and you'll be
On 02/04/13 06:35, jesusthefrog wrote:
> On the topic of 'natural' versus 'synthetic' primary keys, I am
> generally in the camp that an extra ID field won't cost you too much,
> and while one may not need it for a simple table (i.e. id, name) one
> might add any number of columns later, and you'll
On Tue, Apr 2, 2013 at 8:35 AM, jesusthefrog wrote:
> On the topic of 'natural' versus 'synthetic' primary keys, I am generally
> in the camp that an extra ID field won't cost you too much, and while one
> may not need it for a simple table (i.e. id, name) one might add any number
> of columns la
On the topic of 'natural' versus 'synthetic' primary keys, I am generally
in the camp that an extra ID field won't cost you too much, and while one
may not need it for a simple table (i.e. id, name) one might add any number
of columns later, and you'll be glad to have it.
I am, however, against us
On Mon, Apr 1, 2013 at 1:22 AM, Jasen Betts wrote:
> On Mon, Apr 01, 2013 at 07:08:15PM +1300, Tim Uckun wrote:
>> >
>> > how about using an enum instead of this table?
>> >
>> >
>> That's an interesting idea. Are enums mutable?
>
>
> since 9.1 you can add values.
>
> http://www.postgresql.org/
On Mon, Apr 01, 2013 at 07:08:15PM +1300, Tim Uckun wrote:
> >
> > how about using an enum instead of this table?
> >
> >
> That's an interesting idea. Are enums mutable?
since 9.1 you can add values.
http://www.postgresql.org/docs/9.1/static/sql-altertype.html
--
⚂⚃ 100% natural
--
Sent
>
> how about using an enum instead of this table?
>
>
That's an interesting idea. Are enums mutable?
On 2013-04-01, Tim Uckun wrote:
> --14dae93996072d9ff304d945bd3c
> Content-Type: text/plain; charset=UTF-8
>
>>
>>
>> Natural Keys have a purpose but when do they exist in the database?
>>
>>
> In my case it's the tags. Table tags has only two columns id and tag. Each
> one has a unique index. I
>
>
> Natural Keys have a purpose but when do they exist in the database?
>
>
In my case it's the tags. Table tags has only two columns id and tag. Each
one has a unique index. I have many other similar lookup tables. For
example things like order_status, item_type etc.
> What about the Natural
On 1/4/13 at 10:35 AM, Tim Uckun wrote:
Consider the following scenario.
Since I don't consider myself an expert I am talking in basic
terms below. Please don't misunderstand this plodding as
anything other than me attempting to be as clear as possible.
These comments reflect my understandi
On 01/04/13 12:19, Modulok wrote:
> On 3/31/13, Tim Uckun wrote:
>> Consider the following scenario.
>>
>> I have a typical tagging structure. There is a table called tags, there is
>> a table called taggings. The taggings table acts as a many to many join
>> table between the taggers and the tags
On 3/31/13, Tim Uckun wrote:
> Consider the following scenario.
>
> I have a typical tagging structure. There is a table called tags, there is
> a table called taggings. The taggings table acts as a many to many join
> table between the taggers and the tags.
>
> The tags table has two fields id an
--
From: Tim Uckun
Sent: 01/04/2013 01:36
To: pgsql-general
Subject: [GENERAL] Using varchar primary keys.
Consider the following scenario.
I have a typical tagging structure. There is a table called tags, there is
a table called taggings. The taggings table acts as a many to many join
table be
Consider the following scenario.
I have a typical tagging structure. There is a table called tags, there is
a table called taggings. The taggings table acts as a many to many join
table between the taggers and the tags.
The tags table has two fields id and tag. id is a serial data type.
The tagg
21 matches
Mail list logo
