On Aug 10, 2014, at 4:26 PM, Paul <paulste...@afrihost.co.za> wrote:
> Yeah, being able to change these values later is one of the main > reasons to use a separate table. Clients almost *always* end up adding > or removing some of these. > > Also, when you have specific functionality tied to some of these > statuses, it's always a good idea to add a flag field for it, and make > your code check if the flag is on, rather than if the status name > matches a specific value, so that if the client ends up deciding (as > they invariably will) that actually a second status must also do that > thing that they assured you only the one status would ever do, then you > simply turn that flag on for the second status, rather than having to > change your code base and hunt for all instances of checking for the > status by name. > > Also, then you can localize your status names if you ever want to make > your program support other languages. We agree <G> I think my comments passed yours in the mail. I hadn't done any relational database work until this current big project, thats why the database design book I recommended was so critical. It got me out of the spreadsheet mindset and into the database one. Just because it's for one person for one reason doesn't mean you can't design it with proper database functions, after all the structure might be useful to someone else as well. Eugenie (Oogie) McGuire Desert Weyr, LLC - Black Welsh Mountain Sheep http://www.desertweyr.com/ LambTracker - Open Source SW for Shepherds http://www.lambtracker.com Paonia, CO USA -- 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
