Re: How to store opening time of shops?
Date: Sat, 23 Mar 2019 11:20:14 -0400
Message-ID: <q75irf$qqe$1_at_dont-email.me>
^Bart wrote:
>> Thanks for the correction!
>
> I'm sorry but I didn't understood the correction...
Luuk wrote:
Luuk> For holidays (or 'other-than-usual-days') you could define an extra Luuk> table which would hold the deviations: Luuk> Luuk> CREATE TABLE holiday ( Luuk> storeid INTEGER Luuk> , holiday DATE Luuk> , opened TIME Luuk> , close TIME Luuk> , primary key(storeid, dow, opened) Luuk> INSERT INTO schedule (storeid, holiday, opened, close) VALUES Luuk> (123, '2019-12-24', '08:30', '12:30')
To which, I replied with a correction to the primary key:
Lew> Itym
Lew> , primary key(storeid, holiday, opened)
Luuk's pk used a column (dow) that was not part of the table. It appears that Luuk derived his `holiday` table from your `schedule` table definition, with a single column change: removing column `dow`, and replacing it with column `holiday`. However, he overlooked the pk definition, which still named `dow` as a component. Easy enough to do, when replying on the fly to a newsnet post.
I spotted the discrepancy, and posted a correction to the pk definition. This correction used the new `holiday` column instead of the (irrelevant and missing) `dow` column.
However, neither Luuk nor I caught the error with the INSERT statement. Luuk's statement
Luuk> INSERT INTO schedule (storeid, holiday, opened, close) VALUES Luuk> (123, '2019-12-24', '08:30', '12:30')
inserts into table `schedule` where it should insert into table `holiday`.
-- Lew Pitcher "In Skills, We Trust"Received on Sat Mar 23 2019 - 16:20:14 CET