Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.mysql > #6039 > unrolled thread

Design-stage advice and opinions welcomed

Back to article view | Back to comp.databases.mysql

Contents

  Design-stage advice and opinions welcomed Derek Turner <frderek@suremail.je> - 2015-09-24 10:35 +0000
    Re: Design-stage advice and opinions welcomed Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-09-24 22:58 +0200
      Re: Design-stage advice and opinions welcomed Derek Turner <frderek@suremail.je> - 2015-09-24 21:15 +0000
        Re: Design-stage advice and opinions welcomed Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 17:53 -0400
        Re: Design-stage advice and opinions welcomed Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-09-25 04:57 +0200
    Re: Design-stage advice and opinions welcomed Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2015-09-25 13:15 +1000
      Re: Design-stage advice and opinions welcomed gordonb.lizck@burditt.org (Gordon Burditt) - 2015-09-25 17:38 -0500
        Re: Design-stage advice and opinions welcomed Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-09-26 15:16 +0200
        Re: Design-stage advice and opinions welcomed Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2015-09-28 09:46 +1000
          Re: Design-stage advice and opinions welcomed Derek Turner <frderek@suremail.je> - 2015-09-28 03:34 +0000
        Re: Design-stage advice and opinions welcomed Derek Turner <frderek@suremail.je> - 2015-09-28 03:27 +0000
          Re: Design-stage advice and opinions welcomed Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:53 -0400
            Re: Design-stage advice and opinions welcomed Derek Turner <frderek@suremail.je> - 2015-09-28 10:46 +0000
              Re: Design-stage advice and opinions welcomed The Natural Philosopher <tnp@invalid.invalid> - 2015-09-28 12:57 +0100
              Re: Design-stage advice and opinions welcomed Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 09:41 -0400
                Re: Design-stage advice and opinions welcomed bill <william@TechServSys.com> - 2015-09-29 07:14 -0400

#6039 — Design-stage advice and opinions welcomed

Ladies and Gentlemen,

I am tasked with creating a web-site for my local University of the Third 
Age (U3A) and am at the design-stage at present. The HTML and CSS are no 
problem and I have experience in coding a previous dynamic site using PHP/
MySQL. This post is cross-posted to c.d.mysql and c.l.php, both of which 
groups I have been active in (off and on) for some years. So I am NOT 
askimg you to do my homework :) I've set follow-up to the php group.

So far, I've neither created the database nor written a line of php code, 
I'm seeking advice/opinions before I start so as to avoid time-wasting 
mistakes in design. I'd be grateful for any comments on the ideas below.

DATABASE:

At the moment there are 20 groups meeting at various venues at various 
dates and times which people need to know. Each group has a convener, 
people need to know his/her contact details too.

So for each group (typically they meet twice a month) I am thinking about 
the following 9 'columns'

autoincremented number
name
time of meeting
date of 1st meeting e.g. 'first tuesday'
ditto second
venue
convener
telephone of conv.
email of conv.

Some conveners chair two or more groups and more than one group may meet 
at any one venue.

I'm thinking I need at least three tables:

groups
venues
conveners

Is that enough normalization? I realize it's not fully normalized as more 
than one group may meet on the first Tuesday of the month but a table of 
dates seems to be over-egging the pudding? nobody is going to change the 
name of a day to the week?! opinions?

PHP:

I am delightedly discovering the wonderfully versatile strtotime function 
which will simplify matters no end, so long as I store correct syntax in 
the database e.g. 'first Tuesday' rather than '1st tuesday' etc. Also, 
'of this month', 'of next/second month' and 'of third month' are going to 
be REALLY useful. Very cool!

Most of the php will be pretty straightforward - producing a list of 
meeting dates and times for a group (drop-down list of group populated 
from the groups table, etc). The challenge will be producing a complete 
dynamic 'diary' page where the next 100 day's meetings are listed in 
datetime order. I think I'll need a for or while loop but how do I avoid 
querying the database once or twice on each iteration??? Again I'm not 
asking for code but principles to work to, to avoid wasting resources.

Anyway, that's more than enough for the present. If you've read this far 
then thanks for your patience. Feel free to comment on any or all of it.

Thanks again,

Derek

[toc] | [next] | [standalone]

#6040

[Ignoring the F'up2 comp.lang.php and setting F'up2 comp.databases.mysql as 
this is not PHP-specific so far]

Derek Turner wrote:

> DATABASE:
> 
> At the moment there are 20 groups meeting at various venues at various
> dates and times which people need to know. Each group has a convener,
> people need to know his/her contact details too.
> 
> […]
> I'm thinking I need at least three tables:
> 
> groups
> venues
> conveners

Correct.  Consider drawing Entity-Relationship-Diagrams before you do 
anything else.  A correct model goes a long way towards a correctly working 
application.
 
> Is that enough normalization?

You tell me.  Why is it important to normalize databases?

> I realize it's not fully normalized as more than one group may meet on the
> first Tuesday of the month

You need to find a way to store the information “first Tuesday” without 
storing that string in the database.  Because in the Web application, for 
repeating venues you should only be reading one record per venue and 
calculate the rest as needed.  Also, what is stored in the database should 
not depend on the used programming language or the presentation of the data.

> but a table of dates seems to be over-egging the pudding?

Certainly.  Do not make “richard”’s mistakes.

> nobody is going to change the name of a day to the week?! opinions?

Parse error.

> PHP:
> 
> I am delightedly discovering the wonderfully versatile strtotime function
> which will simplify matters no end, so long as I store correct syntax in
> the database e.g. 'first Tuesday' rather than '1st tuesday' etc. Also,
> 'of this month', 'of next/second month' and 'of third month' are going to
> be REALLY useful. Very cool!

Still, simply storing trivial strings as dates is not a viable approach for 
an event calendar.  Can you think of a reason why?
 
> Most of the php will be pretty straightforward - producing a list of
> meeting dates and times for a group (drop-down list of group populated
> from the groups table, etc).

Hopefully you are not considering to write this from scratch, without any 
libraries or frameworks.

> The challenge will be producing a complete dynamic 'diary' page where the
> next 100 day's meetings are listed in datetime order. I think I'll need a
> for or while loop but how do I avoid querying the database once or twice
> on each iteration???

Simple: you do not.  Make a query whose result contains all the information 
you need, and store the result (in a PHP data structure).

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#6041

On Thu, 24 Sep 2015 22:58:49 +0200, Thomas 'PointedEars' Lahn wrote:

> Still, simply storing trivial strings as dates is not a viable approach
> for an event calendar.  Can you think of a reason why

No, I can't. it seems to me to be a excellent and robust way of handling 
this situation. ISTM that what I'm aiming for is not a set-in-stone 
calendar but a way of predicting what will happen, all other things being 
equal. For example, The Aardvard Appreciation group meets on the first 
monday and third tuesday of each month. That's human-readable and takes 
only a few characters to store. OK they won't meet between Christmas Eve 
and New Year's Day, nor the last two weeks of July and the whole of 
August - that's trivial to programme. There's nothing sacrosanct about 
the dates, this is what normally happens, and can easily be retrieved and 
rendered in a group's information because it's human-readable. Seriously, 
what's the problem? genuine question, I'm not doing a Richard.

[toc] | [prev] | [next] | [standalone]

#6042

On 9/24/2015 5:15 PM, Derek Turner wrote:
> On Thu, 24 Sep 2015 22:58:49 +0200, Thomas 'PointedEars' Lahn wrote:
> 
>> Still, simply storing trivial strings as dates is not a viable approach
>> for an event calendar.  Can you think of a reason why
> 
> No, I can't. it seems to me to be a excellent and robust way of handling 
> this situation. ISTM that what I'm aiming for is not a set-in-stone 
> calendar but a way of predicting what will happen, all other things being 
> equal. For example, The Aardvard Appreciation group meets on the first 
> monday and third tuesday of each month. That's human-readable and takes 
> only a few characters to store. OK they won't meet between Christmas Eve 
> and New Year's Day, nor the last two weeks of July and the whole of 
> August - that's trivial to programme. There's nothing sacrosanct about 
> the dates, this is what normally happens, and can easily be retrieved and 
> rendered in a group's information because it's human-readable. Seriously, 
> what's the problem? genuine question, I'm not doing a Richard.
> 

First of all, don't worry about "Pointed Head".  He's a well-known troll
who doesn't know his backside from a hole in the ground - although he is
part of this belongs in comp.database.mysql.  You really should have
split this into two different posts).

As for your question: I think you need another table to identify
when/where the events are taking place.  You have:

time of meeting
date of 1st meeting e.g. 'first tuesday'
ditto second
venue
convener
telephone of conv.
email of conv.

Is it guaranteed none of these will ever change?  I don't think so.
What you need is another event table which has individual meetings are
indicated.  You can fill it with specific dates and time as defaults,
but they could change.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6043

Derek Turner wrote:

> On Thu, 24 Sep 2015 22:58:49 +0200, Thomas 'PointedEars' Lahn wrote:
>> Still, simply storing trivial strings as dates is not a viable approach
>> for an event calendar.  Can you think of a reason why
> 
> No, I can't. it seems to me to be a excellent and robust way of handling
> this situation. ISTM that what I'm aiming for is not a set-in-stone
> calendar but a way of predicting what will happen, all other things being
> equal. […] Seriously, what's the problem? genuine question, I'm not doing
> a Richard.

In addition to what I said in another paragraph: You will have to parse 
those strings in order to select the algorithm for computing the future 
dates from the previous one.

It is much better to use language-independent codes for storing data such as 
“first Tuesday”; for example number=1, weekday=2, repeat=TRUE.  From that 
you can either construct a string for strtotime(), or use another algorithm 
to arrive at the dates (it is easy to determine the date of the first of a 
certain weekday in a month even without strtotime()).

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#6044

On 24 Sep 2015 10:35:48 GMT, Derek Turner wrote:


> I'm thinking I need at least three tables:
> 
> groups
> venues
> conveners
> 
> Is that enough normalization? I realize it's not fully normalized as more 
> than one group may meet on the first Tuesday of the month but a table of 
> dates seems to be over-egging the pudding? nobody is going to change the 
> name of a day to the week?! opinions?
Personally, I'd definitely add a fourth table "meetings" with columns of 
group/venue/day.

Why:

a) You've used the phrase "typically" a future-proofing red flag alert 
that meetings might sometimes end up more than twice per month.  And 
might you have virtual groups that don't even have formal physical 
meetings?

b) Will you ever need to check for group/venue/day clashes?  If so then 
cross checking that will include 1st meeting for one group against both 
1st and 2nd for another will become complex.

And for the "day", I'd consider defining it as a multi-column attribute 
of week-of-month and day-of-week so that they can be stored as just 
integer values, being mindful of regional differences in definition of 
DoW #1 being either Sunday of Monday.

I note in a followup posting that you might code for Xmas, etc. whereas 
I'd possibly recommend creating a "holidays" table as well, to cater for 
one-off venue closures (4th July?) and the moveable beast that is 
Easter.

GM

[toc] | [prev] | [next] | [standalone]

#6047

> a) You've used the phrase "typically" a future-proofing red flag alert 
> that meetings might sometimes end up more than twice per month.  And 
> might you have virtual groups that don't even have formal physical 
> meetings?

If you allow for up to 2 meetings slots for each group you have to
allow for less than 2 meetings a month, so there needs to be a way
to indicate "no meeting" in a slot.  This same method could be used
for virtual groups with no physical meetings.  I prefer a meetings
table, though.

An individual instance of a meeting should be able to have a title.
If there is a speaker, this probably includes the name of the speaker
and the topic.  If there's a project being worked on, describe the
project, e.g. "Raspberry Pi - Software for the Camera".  This
information probably has to be supplied by the convenor when it's
available.
 
> b) Will you ever need to check for group/venue/day clashes?  If so then 
> cross checking that will include 1st meeting for one group against both 
> 1st and 2nd for another will become complex.

I would think that venue/day/time clashes would be more of an issue.
Many venues have more than one time slot in a day for a meeting.
Two groups might decide to meet together one time for a subject of
common interest (e.g. a Raspberry Pi group and a Linux group, since
the Raspberry Pi runs Linux), which is an exception to this.

You also have to deal with the 1st meeting in a month and the 2nd
meeting in a month for the same group might clash.  (e.g. 1st
meeting: 4th Friday, 2nd meeting: last Friday).  It might not be a
problem, but you also don't want it listed on a calendar twice.
It just might be that the first meeting slot describes a meeting with
a guest lecturer, and the second meeting slot describes a work session
where the participants actually build something.  Which type of
meeting happens on the overlap date.

> And for the "day", I'd consider defining it as a multi-column attribute 
> of week-of-month and day-of-week so that they can be stored as just 
> integer values, being mindful of regional differences in definition of 
> DoW #1 being either Sunday of Monday.

Note that things can get complicated here:  "last Friday of the
month" and "4th Friday of the month" may or may not happen on the
same day depending on which month it is (but they would presumably
have a different code for week-of-month, since the formula is
different even though the result might be the same).  Also consider
that some groups just might schedule meetings on the 5th Friday of
every month, which doesn't happen in every month.

Do you need to support having a meeting on the Wednesday after the
first Monday in a month?  How about the Monday after the last Friday
of the month, which just might end up in the next month?  Do you want
to support meeting every Friday the 13th?  (happens 1-3 days a year;
I don't think 0 or 4 in a year can happen with the current calendar).

> I note in a followup posting that you might code for Xmas, etc. whereas 
> I'd possibly recommend creating a "holidays" table as well, to cater for 
> one-off venue closures (4th July?) and the moveable beast that is 
> Easter.

Is Easter really a problem if you don't schedule meetings on Sundays?
Meetings on Sundays tend to conflict with family together time and
some religious attitudes (unless it's a church-related group), and
people seem to hardly ever schedule meetings on Sundays for those
and other reasons.  Also, it seems that if a venue has any day of
the week "closed", it probably includes Sunday (unless it's a
church).

I'd like to also suggest that "holidays", or whatever else you might
call certain conditions that prevent meetings from happening, can
be group-specific or venue-specific, and they might pop up without
a lot of notice.

For example:  a NFL-oriented group will probably not have many
members show up at a meeting on the day of the Super Bowl (unless
perhaps the venue has a gigantic-screen TV that receives the game,
and allow attendees to bring their own beer and snacks), so they
might reschedule that for the next or previous week if possible.
A Linux User's group probably wouldn't care about the Super Bowl,
but they might want to reschedule if there's a local Linux Fest
going on.  A non-Christian church group might not care that a meeting
is scheduled on Christmas or Easter.

You might get a couple of weeks notice that the venue is having
construction work done and is closed during specific (or perhaps
not so specific) times.  You might get less notice about fire damage
and even less about (unplanned) power outages or weather that makes
travel dangerous.  Perhaps there's an alternate venue or perhaps
it will be rescheduled or just cancelled.

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.  If there is a change for
a meeting in month X, it will probably be decided at the meeting
for the prior month by a group vote (if you didn't attend that
meeting, you can find out on the group's web site and/or email is
sent out in advance of a meeting).  Or, it will be announced that
the venue isn't available, and there might or might not be alternate
dates or locations available.

There might be a "work cycle" involved in maintaining the database.
Every so often, such as once a month, a list of meetings in the
next, say, 3 months for a group is sent to the group's convenor.
The convenor should confirm, edit, or cancel the meetings or add
some.  Care should be taken that the calendar rules don't undo
manual edits.

Think about what should happen if you are informed in December that,
effective next April and continuing indefinitely, the group is
switching from meetings on the 2nd Tuesday to meetings on the 3rd
Tuesday, and at the same time is switching venues.  You'd better
not change any meetings to come *before* April, you should immediately
stop showing incorrect meetings that happen in April and later and
show the correct ones instead.  Perhaps those "Nth <day of week"
formulas need a start and end date.

[toc] | [prev] | [next] | [standalone]

#6051

Gordon Burditt wrote:

[restored attribution]

> Derek Turner wrote:
>> b) Will you ever need to check for group/venue/day clashes?  If so then
>> cross checking that will include 1st meeting for one group against both
>> 1st and 2nd for another will become complex.
> 
> I would think that venue/day/time clashes would be more of an issue.
> Many venues have more than one time slot in a day for a meeting.
> Two groups might decide to meet together one time for a subject of
> common interest (e.g. a Raspberry Pi group and a Linux group, since
> the Raspberry Pi runs Linux), which is an exception to this.

venue:

  venue_id  name
  ---------------------------------
         1  Raspberry Pi discussion

meeting:

  meeting_id  venue_id  time_start          time_end
  ------------------------------------------------------------
           1         1  '2015-09-26 09:00'  '2015-09-26 12:00'
           2         1  '2015-09-26 13:00'  '2015-09-26 16:00'

group:

  group_id  name
  ----------------------------
         1  Linux developers
         2  Raspberry Pi users

meeting_group:

  meeting_id  group_id
  --------------------
           1         1  
           1         2
           2         1
 
> It just might be that the first meeting slot describes a meeting with
> a guest lecturer, and the second meeting slot describes a work session
> where the participants actually build something.  Which type of
> meeting happens on the overlap date.

This, too, can be solved by handling the meetings separately, but belonging 
to the same venue.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#6053

On Fri, 25 Sep 2015 17:38:40 -0500, Gordon Burditt wrote:

> I would think that venue/day/time clashes would be more of an issue.

Perhaps.  If so then add time as a column as well.  It reinforces the
argument of having meetings (even if just for meeting recurrence rather
than individual meeting instances which you seem to favour) in a separate
table

> Is Easter really a problem if you don't schedule meetings on Sundays?

Is the prior Friday - and perhaps even the following Monday - not a public
holiday in your region?  Both are here.

Many venues (particularly those under some form of public ownership as is
the case for many U3A locations) are closed on all officially recognised
public holidays, primarily as a security/facility/cleaning savings measure.
Can't use it, even if you "agnostically" wanted to.

GM

[toc] | [prev] | [next] | [standalone]

#6055

On Mon, 28 Sep 2015 09:46:15 +1000, Geoff Muldoon wrote:

> Many venues (particularly those under some form of public ownership as
> is the case for many U3A locations) are closed on all officially
> recognised public holidays

As it happens, nearly all of our venues are convenor's or members homes 
(if indoors). But the point is a very good one.

[toc] | [prev] | [next] | [standalone]

#6054

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

Yep. That's exactly what happens at present. Having read all the answers 
I'm going to go with "These are the normal meetings" Then I'm going to 
have an 'exceptions' table which convenors can populate. Anything else is 
just too much hassle :). I WILL, however, put something in the PHP to 
automatically cancel anything between 24th Dec and 1st Jan inclusive, and 
put a warning about summer and Easter holidays, too.

Thanks for this and all other input, I intend to KISS.

[toc] | [prev] | [next] | [standalone]

#6056

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
> 
> Yep. That's exactly what happens at present. Having read all the answers 
> I'm going to go with "These are the normal meetings" Then I'm going to 
> have an 'exceptions' table which convenors can populate. Anything else is 
> just too much hassle :). I WILL, however, put something in the PHP to 
> automatically cancel anything between 24th Dec and 1st Jan inclusive, and 
> put a warning about summer and Easter holidays, too.
> 
> Thanks for this and all other input, I intend to KISS.
> 

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6058

On Sun, 27 Sep 2015 23:53:46 -0400, Jerry Stuckle wrote:

> 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.

Point taken, but my idea now is to present the exceptions separately on 
the page. So there will a heading on the page something like "normal 
meeting times" then another heading "these are the exceptions of which we 
are aware". No attempt to match.

That's very much the format of the paper-based information currently 
distributed.

[toc] | [prev] | [next] | [standalone]

#6059

On 28/09/15 11:46, Derek Turner wrote:
> On Sun, 27 Sep 2015 23:53:46 -0400, Jerry Stuckle wrote:
>
>> 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.
>
> Point taken, but my idea now is to present the exceptions separately on
> the page. So there will a heading on the page something like "normal
> meeting times" then another heading "these are the exceptions of which we
> are aware". No attempt to match.
>
> That's very much the format of the paper-based information currently
> distributed.
>
It is never a bad idea to base a business IT model on 'the way things 
are done, that works' but sometimes that is the springboard for 'but 
this too will cover those bases and indeed be simpler'

People seem to fear total data normalisation, but unless the application 
is huge, the actual SQL queries, or sometimes high level code algorithms 
to extract insert and update data into such, are not hard nor 
inefficient to perform.

Especially with considered application of indices.

-- 
Global warming is the new Margaret Thatcher. There is no ill in the 
world it's not directly responsible for.

[toc] | [prev] | [next] | [standalone]

#6060

On 9/28/2015 6:46 AM, Derek Turner wrote:
> On Sun, 27 Sep 2015 23:53:46 -0400, Jerry Stuckle wrote:
> 
>> 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.
> 
> Point taken, but my idea now is to present the exceptions separately on 
> the page. So there will a heading on the page something like "normal 
> meeting times" then another heading "these are the exceptions of which we 
> are aware". No attempt to match.
> 
> That's very much the format of the paper-based information currently 
> distributed.
> 

Derek, the eight most dangerous words in business are "Because that's
the way we've always done it."

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6061

On 9/28/2015 9:41 AM, Jerry Stuckle wrote:
> On 9/28/2015 6:46 AM, Derek Turner wrote:
>> On Sun, 27 Sep 2015 23:53:46 -0400, Jerry Stuckle wrote:
>>
>>> 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.
>>
>> Point taken, but my idea now is to present the exceptions separately on
>> the page. So there will a heading on the page something like "normal
>> meeting times" then another heading "these are the exceptions of which we
>> are aware". No attempt to match.
>>
>> That's very much the format of the paper-based information currently
>> distributed.
>>
>
> Derek, the eight most dangerous words in business are "Because that's
> the way we've always done it."
>
followed closely by "Because that's the way I want it."

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.mysql

csiph-web