Joris Dobbelsteen wrote:
Personally I've found nothing that will beat Excel for doing data
analysis. Learn to use the pivot table and pivot charts. They are
extremely powerful.
Funny, there is an on-going discussion about this on one of our
internal mailing lists. Excel is perhaps okay for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 15:18, garry saddington wrote:
> On Sun, 2007-01-28 at 09:57 -0600, Ron Johnson wrote:
>> On 01/28/07 07:05, garry saddington wrote:
[snip]
>> When you say "certain days", you mean "days of the week"?
>>
>> If so, create a view like:
>> CRE
On Sun, 2007-01-28 at 09:57 -0600, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/28/07 07:05, garry saddington wrote:
> > I have a table definition such as:
> >
> > CREATE TABLE attendance
> > (
> > attendanceid serial primary key,
> > entered date DEFAULT cur
"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
> So perhaps What would have been better without surrogate keys
> all-over should have been "My database where I extremely overdid
> it with surrogate keys".
Fair enough. It's generally true that going to extremes with anything
causes problems. :)
>-Original Message-
>From: Douglas McNaught [mailto:[EMAIL PROTECTED]
>Sent: zondag 28 januari 2007 16:29
>To: Joris Dobbelsteen
>Cc: John Meyer; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] counting query
>
>"Joris Dobbelsteen" <[EMAIL PRO
On 1/28/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
This is the great synthetic-vs-natural key debate.
Truly. But what the heck!
Surrogate keys are not evil, and they do have value. I see no value in
proclaiming "surrogate keys are evil, do not use them".
Surrogate keys do have advantages:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 07:05, garry saddington wrote:
> I have a table definition such as:
>
> CREATE TABLE attendance
> (
> attendanceid serial primary key,
> entered date DEFAULT current_date NOT NULL,
> absent boolean,
> authorization text default 'N'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/07 08:36, John Meyer wrote:
> Joris Dobbelsteen wrote:
>>> CREATE TABLE attendance
>>> (
>>> attendanceid serial primary key,
>> Why you have this??? You already have (entered,timeperiod,studentid)
>> that you can use, since that must be uniq
"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
> What would have been better without surrogate keys all-over:
> * Easier to write complex queries with much fewer tables to be queried.
> * Much faster query performance, as fewer tables need to be referenced.
> * Better integrity enforcement with s
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of John Meyer
>Sent: zondag 28 januari 2007 15:36
>To: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] counting query
>
>Joris Dobbelsteen wrote:
>>>
>>> CREAT
Joris Dobbelsteen wrote:
>>
>> CREATE TABLE attendance
>> (
>> attendanceid serial primary key,
>
> Why you have this??? You already have (entered,timeperiod,studentid)
> that you can use, since that must be unique too. Try to avoid surrogate
> keys as much as possible (it really increases perfor
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of garry
>saddington
>Sent: zondag 28 januari 2007 14:06
>To: pgsql-general@postgresql.org
>Subject: [GENERAL] counting query
>
>I have a table definition such as:
I have a table definition such as:
CREATE TABLE attendance
(
attendanceid serial primary key,
entered date DEFAULT current_date NOT NULL,
absent boolean,
authorization text default 'N',
timeperiod char(2) check(timeperiod in('AM','PM')),
days varchar(10),
studentid int,
unique(ente
13 matches
Mail list logo
