>>Soon they ran out of disk space. The table's zip factor was about 1% - regularly it's about 10% for dbf.
>
>I can see that being a problem, but I don't think they'll ever add more days to the week :)

They'll add something else. You see everyone tried to guess what could possibly become more complicated as it usually does.

The point here is that with a cursor you have the trouble of switching between day-of-week and date in only two places - when scattering records from your tables into your whole week cursor, and then when saving those back. For the rest of it, you don't have to change any queries to do a five times join just to get the records for each day of the week into one column. I've seen such things too many times, and have developed an organic dislike. Just think of all those Phone1, Phone2, Phone3 fields, which happened because the app and the tables were designed in the times where everyone had just one phone number. Then they had a pager too, so that was added as well... and in the end you had up to seven kinds of phone fields, where they'd use no more than two in the average. You'd still have to do some kind of seven-fold join in some cases to put these together, instead of having an arbitrary number of such phone records in a child table and querying them at will.

You already have a normalized database. If they want it to have one form where it's displayed and entered in some denormalized shape, let them have it, but (since you asked for advice), if you add this to your tables and later regret it, you owe us all a drink. I guess it would be rum, right?