Database Concepts & Design | Forum profile

Yeah, and read your textbook and lecture notes first, as well.

Then it looks like you should follow dportas's solution in this case. It might of been worth mentioning the number of types of objects that you were planning on storing as this does influence suggested designs - I guess 2 million trillion tables might be a bit much to look after in this case. Though there is a guy on the MySQL forum at the moment with 100 thousand tables in his database.

Quote: Originally Posted by blindman Really? Cuz, I dropped out of Sybase seven years ago after attending a conference in Florida where it became abundantly clear to me that it is a dead and stagnant platform. I suppose if you never want to learn anything new and more powerful, or are incapable of adapting to change, then legacy systems such as sybase are the best career choice for you. Do tell? Blindman, This thread is quite revealing,...

I would post your question and your work so far. I will move this post to Database Concepts and Design. Be warned now - we will not do your homework for you. You will do all the work and we will nudge you if you start going down a blind alley.

Yeah, and read your textbook and lecture notes first, as well.

Quote: Originally Posted by programmer newbee Hi Guys, I am new to programming, so kindly bear me I am working on a project where parameters needed for database connection will be provided only once to the application. The question is how and where to save such information to use the parameters for later use ? which format will be secure ? Thankx Use some form of integrated / single-signon security such as Active Directory. Attempting to...

Wikipedia has a decent article on temporal database design. Usually you would add a ValidStart and ValidEnd datetime columns to reflect when the row was current. The current record has a ValidEnd datetime of some specific date in the distant future so it is easy to find. If you are going to have a huge number of document revisions (more than 20 per document) then I would go with an archive table, otherwise keeping it in one table is best.

Normally I would recommend an archive table, but in your case records are not being "permanently archived", and can be change back to an active state. So, the single table may be your best option. Note though, that a single table with start and stop columns will not enable you to determine the history of when a document was in use (if it had multiple start and stop times), while an archive table would.

The OP is grateful to you both for taking the time to answer Actually, both answers were thoroughly useful. The assignment initially concerns modelling historical data that isn't going to be subject to any change - no chance of anomalies occuring. It then goes on to ask how the model could be ammended to provide better integrity, flexibility, etc. should a requirement arise that further data be added. Thanks to you both I am far more...

OK, I would have a Document table, With Effective and Termination Dates (null), with a version Number for the document that is incremented by 1 any time the document was modified (via a trigger) I would also move all data images to a history table (via a trigger) when anything on the row was modified MOO