Re: SOT Database design

2006-09-13 Thread Victor Moore
] 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

SOT Database design

2006-09-12 Thread Victor Moore
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

RE: SOT Database design

2006-09-12 Thread Tom Kitta
, 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

Re: SOT Database design

2006-09-12 Thread Matt Williams
: 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

RE: SOT Database design

2006-09-12 Thread Tom Kitta
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

Re: SOT Database design

2006-09-12 Thread Jochem van Dieten
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