I do this too – one table and select with a where clause. Apart from the ease I find in having one table I also tend to see where I might be duplicating something and can then standardise more efficiently. I have not noticed a downside at all. I also use my equivalent of MenuSeq so that the menus can be sorted as I want them rather than alpha/numeric so that the most frequent choices might be first or second or last to reduce keystrokes.
I also use a variable, vCount, which I set to limit the depth of the menu so that the most relevant choices only are displayed. Because all menus follow this standard it becomes very easy to make changes and keep the display consistent. Regards, Alastair. From: Mike Byerley Sent: Saturday, May 25, 2013 12:39 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Primary key While you are at it, "numerous tables" strikes a chord with me as being unnecessary. I use a single table structure like: CREATE TABLE `MenuTable` + (`MenuName` TEXT (12) NOT NULL , + `MenuSeq` INTEGER NOT NULL , + `MenuText` TEXT (50) NOT NULL , + `ReturnValue` TEXT (16) NOT NULL ) COMMENT ON TABLE `MenuTable` IS + 'S - Various Menu TEXT and Return Values' You can see it is not indexed at all as it only contains a few hundred rows, but if it ever became noticibly sluggish, I would put an index on the menuname. MenuSeq was added after a year or so, when I wanted something at the top selection that OrderBy wouldn't provide. All return values are TEXT, and when the result needs to be otherwise, the values are converted at runtime. ----- Original Message ----- From: "TOM HART" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Friday, May 24, 2013 11:10 PM Subject: [RBASE-L] - Primary key I am in the process of redoing my database that I've used for over 10 years, just trying to use logic in naming, correct syntax, etc. I have numerous tables that hold data to use to fill fields from popup menus and just wanted to know if it is better to set the field as a PK or unique, they do not reference other tables so there are no foreign keys. Is one way better that the other, just curious Tom Hart
