Valentin Bogdanov schrieb:
--- On Mon, 11/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
From: Gregory Stark [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using PK value as a String
To: Jay [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
Jay [EMAIL
PROTECTED] wrote:
Valentin Bogdanov schrieb:
--- On Mon, 11/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
From: Gregory Stark [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using PK value as a String
To: Jay [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10
Mario Weilguni [EMAIL PROTECTED] writes:
UUID is already a surrogate key not a natural key, in no aspect better than a
numeric key, just taking a lot more space.
So why not use int4/int8?
The main reason to use UUID instead of sequences is if you want to be able to
generate unique values
In response to Gregory Stark [EMAIL PROTECTED]:
Mario Weilguni [EMAIL PROTECTED] writes:
UUID is already a surrogate key not a natural key, in no aspect better than
a
numeric key, just taking a lot more space.
So why not use int4/int8?
The main reason to use UUID instead of
Bill Moran wrote:
The main reason to use UUID instead of sequences is if you want to be able to
generate unique values across multiple systems. So, for example, if you want
to be able to send these userids to another system which is taking
registrations from lots of places. Of course that only
Mark Mielke [EMAIL PROTECTED] writes:
- Increased keyspace. Even if keyspace allocation is performed, an int4
only
has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
allocated as an example of how this can happen. 128-bits has a LOT more
keyspace than 32-bits
Hi!
We use normal sequences to generate id's across multiple nodes. We
use the increment parameter for the sequence and we specify each
node to increment its sequence with for example 10 and the the first
node to start the sequence at 1 and the second at 2 and so on. In that
way you get
Gregory Stark wrote:
Mark Mielke [EMAIL PROTECTED] writes:
- Increased keyspace. Even if keyspace allocation is performed, an int4 only
has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
allocated as an example of how this can happen. 128-bits has a LOT more
On Tue, Aug 12, 2008 at 9:46 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Mark Mielke [EMAIL PROTECTED] writes:
- Increased keyspace. Even if keyspace allocation is performed, an int4
only
has 32-bit of keyspace to allocate. The IPv4 address space is already over
85%
allocated as an
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id
user2.id)
or you can see how many new users registered in a specific period of
time
(compare the id of the newest user to the id a week ago).
In response to Moritz Onken [EMAIL PROTECTED]:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id
user2.id)
or you can see how many new users registered in a specific period of
time
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken [EMAIL PROTECTED]:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id
user2.id)
or you can see how many new users registered
In response to Moritz Onken [EMAIL PROTECTED]:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken [EMAIL PROTECTED]:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id
Am 12.08.2008 um 17:21 schrieb Bill Moran:
In response to Moritz Onken [EMAIL PROTECTED]:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken [EMAIL PROTECTED]:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has
In response to Steve Atkins [EMAIL PROTECTED]:
On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
In response to Moritz Onken [EMAIL PROTECTED]:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken [EMAIL PROTECTED]:
We chose UUID as PK because there is still
Bill Moran wrote:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else
(user1.id
user2.id)
or you can see how many new users registered in a specific period
of
time
(compare the id of the newest user to the
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default ''
etc...
);
The UserID is a character(40) and is generated using UUID function. We
Jay [EMAIL PROTECTED] writes:
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default ''
etc...
);
The UserID is a character(40)
--- On Mon, 11/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
From: Gregory Stark [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using PK value as a String
To: Jay [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
Jay [EMAIL PROTECTED] writes:
I have
-13072
贸易通ID:jaymo 淘宝ID:jackem
公司网站:www.alisoft.com
wiki:http://10.0.32.21:1688/confluence/pages/viewpage.action?pageId=10338
-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Jay
发送时间: 2008年8月11日 15:35
收件人: pgsql-performance@postgresql.org
主题: [PERFORM] Using PK value as a String
On Aug 11, 2008, at 4:30 AM, Gregory Stark wrote:
Jay [EMAIL PROTECTED] writes:
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default ''
Valentin Bogdanov wrote:
--- On Mon, 11/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
From: Gregory Stark [EMAIL PROTECTED]
Subject: Re: [PERFORM] Using PK value as a String
To: Jay [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
Jay [EMAIL
22 matches
Mail list logo
