David, On Tue 2002-12-31 at 06:47:38 -0500, [EMAIL PROTECTED] wrote: [...] > Oh, I see... I've been thinking about that, too; I currently use a > datetime field, but all I really need is a date and an hour. I figure > with one combined field I can match against XXXX-YY-ZZ% but maybe two > fields would make it easier to pull out the time column...
well, using one field looks fine to me. Both approaches have their advantages and disadvantages and unless you see a particular problem (sounds familiar? ;-), just go with the simpler solution (one column). [...] > Now I presume that I will want a unique index for (instructor,timeslot) > and a[nother] unique index for (client,timeslot). I can't do a unique > index on the place because some rooms are booked for groups (I'm planning > to create 12 records for a 12-seat class when it's defined, and then I'll > update those records until there are no more with empty client values as > I add students). > > Do I want two unique indexes like that[...]? Correct. [...] > You may. If you know anyone who wants to buy it for me for a belated > Christmas present, you can suggest that, too :-) :-) [...] > % http://lists.mysql.com/cgi-ez/ezmlm-cgi?1:mss:77486 > % http://lists.mysql.com/cgi-ez/ezmlm-cgi?1:mss:115591 > > Thanks; I'll read them next. [Actually I just popped out and read them.] > Oh, I get it; an index is a fast BTree pointer to the data; it's a hash > table! Cool. Yes, that's what I want, all right. Just a minor clarification: "it's *like* a hash table" in its *purpose*. Actually, MySQL even supports real hashes for in-memory tables (TYPE=HEAP), so I thought it's worth pointing out. [...] > Yeah. I won't have that few; I'll have about 80 per week (6a thru 7p on > six days) for every week from now until the end of time (hey, I can hope > that I'll be making money from this software for that long!). So in the > beginning I'll have fewer time slots, but by the end of the first year > that will very probably have flipped... > > Good grief; what do you do in that case? Depends (familiar, isn't it? ;-). From what I heard until yet, I assume that MySQL will easily handle your database, so having a sub-perfect index should be fine. So go long-term, since with fewer rows the index doesn't matter that much. > Well, I suppose it's an opportunity to charge for an annual tuneup ;-) [...] Of course. ;-) If it is anything like the projects I know, you will "correcting" your application to client's wishes long before a year has passed. HTH and a HNY ;) Benjamin. -- [EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
