views:

57

answers:

1

I am designing a database for an ASP.NET MVC application. I'm an expert in neither, and I'm curious what the best approach would be for the following database snippet:

We will be storing Events in our database. Each event will be of a different type with various fields exclusive to one or some of the types. An example:

Events
* Id
* EventTypeId
* AllEventTypes_Field

EventType0
* EventId (FK)
* EventType0_Field

EventType1
* EventId (FK)
* EventType1_Field

We'll have a handful of event types in the end. I am tempted to put all fields into one large Events table, with nullable fields where appropriate. Or, we can separate out the tables into Supertype/Subtype: Events, EventType1, EventType2, etc (As above).

For the database design portion, I want to choose what makes the most sense and is "easiest" for the MVC framework. Essentially: what path will yield the least amount of headaches? :)

For super/sub types, would it be a matter of dragging over the Events table and creating classes for each subtype off of the main Events table? If so, links to articles on this would be very helpful.

Thanks for any and all insight!

+1  A: 

This Microsoft article discusses optional one-to-one relationships, which is essentially what you are describing:

http://msdn.microsoft.com/en-us/library/dd326769(VS.85).aspx

Robert Harvey
Thanks for the link, Robert. I'm also looking for information on how LINQtoSQL and/or EF can handle what that article is talking about.
Dan
Creating classes in Linq to SQL or EF is a simple matter of dragging the tables over to the Linq to SQL designer from the Server Explorer. A one to one link should automatically be established between the classes. In your code, the link should be accessible like this: `MyEvent.EventType1.EventType1_Field`
Robert Harvey
Say I abandon the 1:1 link and have one large table. Does it make sense to then break the table up into separate subtypes/LINQ classes?I bring this up as there are some properties that exist on maybe 1/2 of the subtypes - so I'm tempted to just have one large database table, but have multiple classes in my data layer - feasible/possible?Many thanks for the input, Robert :)
Dan
Unless you have separate tables I don't see anything to be gained by having separate classes.
Robert Harvey