Paul wrote:
On Sun, 10 Aug 2014 21:30:18 +0100
Mark Bourne wrote:
It looks like each book should only have one of the "ReadStatus"
flags set, so I'd make that an enum field on the BookInformation
table, with possible values of "Not Read", "Reading" and "Read". You
can set the default value for the field to "Not Read" so a new record
will be set to that status if no value is specified for that field.
That's essentially the same idea as the status tables I was suggesting.
Indeed; I think our replies crossed in the post ;o)
In my experience we've always used status tables, so I would suggest
those.
I wouldn't dispute that.
Partly because I'm not familiar with database support for enums.
How well supported and widely supported is that by the most common
databases?
I don't know to be honest, not having a lot of experience in database
design. I've only ever really used MySQL, which does support enums, but
maybe that's just a MySQL feature.
To me, the set of possible status values just seems more like part of
the database schema design than data entry - you wouldn't generally add
or remove status options (and the application may assign special meaning
to certain statuses, so it may be critical that a specific set of values
is defined). Then again, in some applications being able to introduce
new statuses at any time could be an advantage.
Mark.
--
To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
