Re: Design-stage advice and opinions welcomed

On 9/27/2015 11:27 PM, Derek Turner wrote:
> On Fri, 25 Sep 2015 17:38:40 -0500, Gordon Burditt wrote:
>

>> I attend several groups that meet monthly.  Generally the best you can
>> get farther out than the next month is a *tentative* date, which is
>> accurate maybe 80 - 90% of the time

I think you'll find handling both a "normal" table and an "exceptions" table to be much harder to handle.

First of all, your "group" table is not normalized (it has duplicated information in I would have one table with the descriptions of the "normal" times, i.e. first and second meeting dates - violation of 1NF).

What happens if some meeting changes and they decide to have it weekly, for instance?

I would have a second table with the group id, meeting id (i.e. 1 or 2) and the meeting date/time ("first tuesday" could work, but limits you - strtotime() is a great function but pretty much limits you to PHP, which may be ok).

Then I would have another table "meetings" with the group id, actual date/time of the meeting and the convener id (conveners can change). This can be pre-filled once a month or once a year or whenever. The meeting information can be changed as necessary.

And if you will have two or more groups meeting together, I would create a link table. Take away the group id from the "meetings" table and replace it with an autoincrement (meeting id). Then create a link table with a group id and the meeting id and fill it in accordingly.

This may all seem like a bit of a hassle - but in the long run it will be a lot less than trying to match information across multiple tables. Proper normalization doesn't require much more work - but makes the code a lot easier to understand and write.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================