]
Sent: Tuesday, September 12, 2006 5:54 PM
To: CF-Talk
Subject: Re: SOT Database design
Knowing that future event types may be added, I vote for option 1. It
feels wrong to have have a bunch of sometimes unnecessary fields. If
you're on MSSQL (probably doable in other DBs, but I wouldn't know
Hi,
I have a database design question. I have to model a db to capture multiple
types of events. While all of them are events the information needed to be
captured for each subcategory of event is quite different.
I think there are (at least) two ways of doing it:
1. Have a master event table
, 2006 4:14 PM
To: CF-Talk
Subject: SOT Database design
Hi,
I have a database design question. I have to model a db to capture multiple
types of events. While all of them are events the information needed to be
captured for each subcategory of event is quite different.
I think there are (at least) two
: Victor Moore [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 4:14 PM
To: CF-Talk
Subject: SOT Database design
Hi,
I have a database design question. I have to model a db to capture multiple
types of events. While all of them are events the information needed to be
captured
SQL.
-Original Message-
From: Matt Williams [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 5:54 PM
To: CF-Talk
Subject: Re: SOT Database design
Knowing that future event types may be added, I vote for option 1. It
feels wrong to have have a bunch of sometimes unnecessary
Tom Kitta wrote:
Just don't forget that its faster to query DB directly then use a View (not
by much)
Could you elaborate? Why is this so and to which databases does it apply?
Jochem
~|
Introducing the Fusion Authority
6 matches
Mail list logo