Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm designing a website for an annual event. The events are similar but mostly independent year-to-year. I see 2 possible designs:

  1. A single schema with most tables having an EventID column to tag data to specific year. Possibly have views for each year.

  2. Multiple schema one per event. The events are independent, so it would be plausible to simply copy a schema and purge old data for each year.

I'd have multiple schemas for faster performance, ease of change, and programming simplicity, but I also feel that a single schema has its advantages such as database simplicity, uniformity, and easier access to old data (not common).

  • Which approach is preferable?
  • Any real world experiences on this?

Thanks.

share|improve this question
add comment

migrated from stackoverflow.com Sep 24 '11 at 4:11

This question came from our site for professional and enthusiast programmers.

1 Answer

up vote 5 down vote accepted

the 'cleaner' solution would definitely using a single schema, and relate your data to a specific event, either with a EventID column, or yet better, using an Events table, relating your data to a row in this table (but keep it simple, you don't need to relate every row in every table to your event, just the 'top-most' objects)

but on the other hand, maybe 'You Aint Gonna Need It', a lot can change in a year, and you'll probably have to make a lot of changes and improvements for next years event. anyway you'll find yourself carrying over and migrating data which nobody needs or wants, so you may end up purging your database after all.

i learned to stick to the YAGNI rule the hard way several times, and keeping things simple always proofed to be the better solution. as long as you produce clean and maintainable code, it's often much simpler to add functionality, than to trim unneeded (and often untested) fat

share|improve this answer
    
+1 for YAGNI. For something like an event database, a simple clone (and warp-if and when necessary) will be the lowest overall cost solution. If you were doing many events (not one annual event) then that might be a different matter. Code maintenance for past events is irrelevant, because they're in the past and you won't need to be using that exact system into the future. –  Joel Brown Sep 25 '11 at 15:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.