"Ross J. Reedstrom" wrote:
>
> On Fri, Feb 25, 2000 at 06:25:12PM -0600, [EMAIL PROTECTED] wrote:
> > oops, it's "timestamp" now (just name change).
> > BTW, I remember datetime is in sql92. "timestamp" is also in sql92? why
> > "timestamp" is better than "datetime" ? sql99(96) ?
>
> Nope, DATE
On Fri, Feb 25, 2000 at 06:25:12PM -0600, [EMAIL PROTECTED] wrote:
> oops, it's "timestamp" now (just name change).
> BTW, I remember datetime is in sql92. "timestamp" is also in sql92? why
> "timestamp" is better than "datetime" ? sql99(96) ?
Nope, DATETIME is not an SQL92 type, it's a class of
t; From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, February 25, 2000 11:08 AM
> To: [EMAIL PROTECTED]; Barnes
> Cc: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] scheduling table design
>
>
> The advantage of (3) is tha
ECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, February 25, 2000 11:08 AM
To: [EMAIL PROTECTED]; Barnes
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] scheduling table design
The advantage of (3) is that it would be extremely easy to write an
application around. However
;[EMAIL PROTECTED]>
Date: Friday, February 25, 2000 10:51 AM
Subject: Re: [GENERAL] scheduling table design
>[EMAIL PROTECTED] wrote:
>>
>> The advantage of (3) is that it would be extremely easy to write an
>> application around. However, the inflexibility of it makes my stoma
[EMAIL PROTECTED] wrote:
>
> The advantage of (3) is that it would be extremely easy to write an
> application around. However, the inflexibility of it makes my stomach
> tighten. I agree with kaiq, I think you're making a mistake.
Hmmm. What would a SQL query look like in (3) that finds all
TED]>
To: Barnes <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>;
[EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, February 25, 2000 9:12 AM
Subject: RE: [GENERAL] scheduling table design
>3) is weird. it looks like a typical mistatke that use the data
>as
On Fri, 25 Feb 2000, Patrick Welche wrote:
> On Fri, Feb 25, 2000 at 09:56:59AM -0600, [EMAIL PROTECTED] wrote:
> >
> > do not use date, use datetime. why? it's sql92 standard (another
> > good reason: M$sql only has datetime :-). A lot of useful functions
> > only apply to datetime, not date.
On Fri, Feb 25, 2000 at 09:56:59AM -0600, [EMAIL PROTECTED] wrote:
>
> do not use date, use datetime. why? it's sql92 standard (another
> good reason: M$sql only has datetime :-). A lot of useful functions
> only apply to datetime, not date.
On a side note: if I have a date d and a time t column
3) is weird. it looks like a typical mistatke that use the data
as the schema. It is not flexible and waste of disk (ya, I know
it cheap. but it you waste too much!). And, more importantly,
you gain nothing. the "correct" table is already so simply!
do not use date, use datetime. why? it's sql92
First, let me start off by thanking you two for the design ideas. You've
been very helpful, as have Ed and Omid who focused more on laying the
groundwork for approaching the problem.
Maybe I'm overcomplicating things. You both seem to be suggesting a table
something like:
1) date | doctor |
11 matches
Mail list logo
