Re: data modelling question - job vs. job history table

2003-11-14 Thread Yechiel Adar
It all depends on the frequency of your scheduler.. If it wakes up every 10 seconds the blocks are already in memory so updating the bitmap will not involve that much overhead. Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent:

Re: data modelling question - job vs. job history table

2003-11-13 Thread Yechiel Adar
I usually use a switch in the scheduled job tables to indicate active status. After the job run jus NULL or put another value in it. If you put bitmap index on this the search will be a snap. There is no reason to hold this pointer in the jobs table. Yechiel Adar Mehish - Original Message

RE: Re: data modelling question - job vs. job history table

2003-11-13 Thread Stephane Faroult
My personal preference is with solution 2 - moving the current information to JOB. The scheduler can quietly insert into JOB_HISTORY when it is done with a job, and update the current line (do it through triggers if you like). Solution 3 violates the beloved KISS principle ... Moreover, when

RE: data modelling question - job vs. job history table

2003-11-13 Thread Mercadante, Thomas F
Jacques, Why make it sooo complicated? I like the third table - Job_History that shows what job ran and when. Much clearer now, and in a year from now when you (or someone else) goes and reviews what you did. Tom Mercadante Oracle Certified Professional -Original Message- Sent:

Re: data modelling question - job vs. job history table

2003-11-13 Thread Jared . Still
Jacques, What you are doing is not exactly data modeling: you are designing a database. When data modeling, the database to be used is irrelevant. There are no columns or primary keys, but there are attributes, and one or more unique identifiers. From a DM perspective, I would be first

RE: data modelling question - job vs. job history table

2003-11-13 Thread Jacques Kilchoer
-Original Message- Mercadante, Thomas F Why make it sooo complicated? I like the third table - Job_History that shows what job ran and when. Much clearer now, and in a year from now when you (or someone else) goes and reviews what you did. Because I can? Because when I make

RE: data modelling question - job vs. job history table

2003-11-13 Thread Jacques Kilchoer
-Original Message- [EMAIL PROTECTED] What you are doing is not exactly data modeling: you are designing a database. I stand corrected. I am actually looking at a denormalized set of tables we have here (there's a table with 52 columns: OBSERVATION1, OBSERVATION2, ... OBSERVATION52)

RE: Re: data modelling question - job vs. job history table

2003-11-13 Thread Jacques Kilchoer
Merci beaucoup Monsieur. I agree with your point in the second paragraph. -Original Message- Stephane Faroult My personal preference is with solution 2 - moving the current information to JOB. The scheduler can quietly insert into JOB_HISTORY when it is done with a job, and

RE: data modelling question - job vs. job history table

2003-11-13 Thread Jacques Kilchoer
-Original Message- Yechiel Adar I usually use a switch in the scheduled job tables to indicate active status. After the job run jus NULL or put another value in it. If you put bitmap index on this the search will be a snap. Except would you put a bitmap index on a column in a