Terri Jarus
jarus at amerinet-gpo.com
Tue Feb 17 06:34:44 CST 2004
Thanks for responding. What I have is a group of Programs - about 10 of them. Then a group of Facility Types - about 12-15 of those. And then, a group of Price Types - about 7 of those. They have remained fairly consistent with an addition or deletion over time - but nothing major. Basically keeping them as Boolean fields is the easiest, but it looks messy and I thought there might be a better way. Since there's no real big advantage to making a switch, I guess I'll stay with the current setup. Thanks again. Terri Jarus Director, Contract Support Services jarus at amerinet-gpo.com 314-542-1902 >>> jwcolby at colbyconsulting.com 02/16/04 09:11PM >>> Terri, There is no "best" answer for this kind of question. Drew has pointed out some of the considerations, specifically the storage size etc. The most important thing to determine is "will there EVER be more of these things. If so then using fields just sucks since to add a new type you have to clear all the users out and add a new field, add it to queries, forms and reports. If these types may EVER change then adding a "child" table allows you to add in new types simply by adding a new record. That said, some types of reports are MORE difficult with child records since to see "counts" of these across a graph you now have to do crosstabs etc. If this is a "control"program where the types are well defined, there are just a handful, they can be implemented as bits in a long (for example) and you need SPEED in comparing them to values in other records then setting up bitmasks and representing them as bits in a long integer can be quite useful. So again, what is the end use? How many of these things are there? Can their names change over time? Can the number of them change over time? Are they used to switch on / off relays in an assembly line or map photocells in a control widget or just "label" an object or a property of an object? It sounds to me like you can have N of M of them for any given contract, the number of these codes could change over time (tomorrow you might need N of X of them), and thus the flexibility of a "lookup table" of these codes, with a m-m between the lookup table and the contract table would give the ability to handle anything that life might throw at you. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Terri Jarus Sent: Monday, February 16, 2004 4:56 PM To: accessd-owner at databaseadvisors.com Subject: [AccessD] Checkboxes/MultiSelect Listbox - What's Best? I'm redesigning an existing database that is not fully normalized. Here is an example where I'm not sure the best way to handle. Current db has a field (Boolean) for each program: AS, DI, MS, SS, LB, NU for example and the user checks the applicable box(es) that are related to their contract. I was going to use a Multiselect Listbox and have it save a string value to the field Programs - but, I would need the string value to be in a consistent order. Another idea would be to save a record for each program in a Programs table. Which is the best route to follow? Any suggestions? If you need more information, just let me know. Thank you for your input. Terri Jarus Director, Contract Support Services jarus at amerinet-gpo.com 314-542-1902 --------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individuals or entities to whom they are addressed. If you have received this email in error please return it to the sender, and erase any copies thereof. Copyright 2004 Amerinet 1nc. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com