On Fri, Feb 10, 2012 at 7:49 AM, Vincent Veyron wrote:
> Le jeudi 09 février 2012 à 16:30 -0600, Merlin Moncure a écrit :
>
> > natural/surrogate is a performance/usability debate with various
> > tradeoffs. but using surrogate to 'create' uniqueness is a logical
> > design error; maybe a very f
On Feb 10, 2012, at 14:56, Vincent Veyron wrote:
> Le vendredi 10 février 2012 à 14:19 -0500, David Johnston a écrit :
>
>> One possibility is to add a "version" field (integer) and combine evenement
>> and version to create the unique. I'd also create a partial unique on
>> evenement/annule
Le vendredi 10 février 2012 à 14:19 -0500, David Johnston a écrit :
> One possibility is to add a "version" field (integer) and combine evenement
> and version to create the unique. I'd also create a partial unique on
> evenement/annule to ensure you do not make more than one active version.
>
On Feb 10, 2012, at 10:49, Vincent Veyron wrote:
> Le jeudi 09 février 2012 à 16:30 -0600, Merlin Moncure a écrit :
>
>> natural/surrogate is a performance/usability debate with various
>> tradeoffs. but using surrogate to 'create' uniqueness is a logical
>> design error; maybe a very forgivabl
Le jeudi 09 février 2012 à 16:30 -0600, Merlin Moncure a écrit :
> natural/surrogate is a performance/usability debate with various
> tradeoffs. but using surrogate to 'create' uniqueness is a logical
> design error; maybe a very forgivable one for various reasons, but the
> point stands.
Please
On Thu, Feb 9, 2012 at 2:10 PM, David Salisbury wrote:
>
>
> On 2/9/12 10:08 AM, Rich Shepard wrote:
>
>> I have reports containing macroinvertebrate collection data for several
>> hundred (or several thousand) of taxa. There is no natural key since there
>> are multiple rows for each site/date
On Thursday, February 09, 2012 5:18:19 pm David Salisbury wrote:
> On 2/9/12 5:25 PM, Rich Shepard wrote:
> > For water quality data the primary key is (site, date, param) since
> > there's only one value for a given parameter collected at a specific
> > site on
> > a single day. No surrogate key n
On 2/9/12 5:25 PM, Rich Shepard wrote:
For water quality data the primary key is (site, date, param) since
there's only one value for a given parameter collected at a specific
site on
a single day. No surrogate key needed.
Yea. I was wondering if the surrogate key debate really boils down to
On Thu, 9 Feb 2012, Merlin Moncure wrote:
If you can't (which happens on various type of data), then the surrogate
is giving the illusion of row uniqueness when there isn't one.
Ah, but each row is unique. However, there is no consisten set of non NULL
values that can consistently define a u
On Thu, 9 Feb 2012, David Salisbury wrote:
Interesting. I used to think natural keys were okay, but have since decided
that surrogates are the way to go. That second layer of abstraction allows
for much easier data modifications when needed. What would be an example
of a natural key that woul
On 2/9/2012 4:20 PM, Andy Colson wrote:
On 2/9/2012 4:10 PM, David Salisbury wrote:
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since
there
are multiple rows for
On Thu, Feb 9, 2012 at 4:20 PM, Andy Colson wrote:
> On 2/9/2012 4:10 PM, David Salisbury wrote:
>>
>>
>>
>> On 2/9/12 10:08 AM, Rich Shepard wrote:
>>>
>>> I have reports containing macroinvertebrate collection data for several
>>> hundred (or several thousand) of taxa. There is no natural key si
On 2/9/2012 4:10 PM, David Salisbury wrote:
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since
there
are multiple rows for each site/date pair. Years ago Joe Celko
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since there
are multiple rows for each site/date pair. Years ago Joe Celko taught me to
seek natural keys whenever th
On Thu, 9 Feb 2012, Andy Colson wrote:
If you create a serial column, dont put the column name or a value into your
insert statement.
create table junk (id serial, stuff text);
insert into junk(stuff) values ('my stuff');
Andy,
That's what I assumed would work but did not know for sure.
On Thu, Feb 9, 2012 at 9:49 AM, Rich Shepard wrote:
> I have a lot of data currently in .pdf files. I can extract the relevant
> data to plain text and format it to create a large text file of "INSERT INTO
> ..." rows. I need a unique ID for each row and there are no columns that
> would make a n
On 2/9/2012 10:49 AM, Rich Shepard wrote:
I have a lot of data currently in .pdf files. I can extract the relevant
data to plain text and format it to create a large text file of "INSERT
INTO
..." rows. I need a unique ID for each row and there are no columns that
would make a natural key so the
On Thu, 9 Feb 2012, Merlin Moncure wrote:
The record should be logically unique as well as physically unique (of if
it isn't, why bother making a unique constraint at all?). Sometimes you
*have* to force a surrogate, for example if certain (broken) client tools
need a primary key to work, but as
On Thu, Feb 9, 2012 at 10:49 AM, Rich Shepard wrote:
> I have a lot of data currently in .pdf files. I can extract the relevant
> data to plain text and format it to create a large text file of "INSERT INTO
> ..." rows. I need a unique ID for each row and there are no columns that
> would make a
19 matches
Mail list logo
