The structure of the tables is a lot more dependant on how they are used. A single table may or may not be the way to go, depending on the characteristics of your queries, and of the tries. For instance: If you need to query all databases to find something other than the primary key often, a one table structure is probably the best; however, if all your queries, after the insert assume that the lookup row exists, and will only look for values from that, a table for each try would probably be best. When your database gets big, and you look for the 'ended' value for try three of jobpid 200, and you know jobpid 200 exists in the try 3 table, the query may be a great deal faster.

On the other hand, if you want to only retrieve jobs with more than three tries for your error logs, then a single database with a'WHERE try = 4' clause.

But what if tries 3 and 4 never have some trait. Do you want to leave it blank in your single table?

I would recommend making the decision of database structure on my own or putting out as much code, and as many facts as possible. Database structure is always a touchy subject, when getting developmental suggestions, because as adrianh points out, a single table is much more flexible; however, you must decide how much flexibility you are willing to sacrifice for speed. You may want to read up on Database Normalization 1 2, before you decide what the structure of you database will be. While youdevelop your 'project'(of which we know very little, and therefore our suggestions may be completely wrong), adrianh's suggestion of a single table is the right one.

---

I could be completely wrong
Gyan Kapur
gyan.kapur@rhhllp.com