A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

"Evils of Lookup FIelds"?



 
 
Thread Tools Display Modes
  #1  
Old November 15th, 2004, 10:57 PM
el zorro
external usenet poster
 
Posts: n/a
Default "Evils of Lookup FIelds"?

SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
(Thanks!)
  #2  
Old November 16th, 2004, 12:48 AM
Joan Wild
external usenet poster
 
Posts: n/a
Default

el zorro wrote:
SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?


I don't think so. It's just that it is quite rare to have a list of values
that will *never* change or be added to.

If you do then fine, but you have quite a bit of work to do if you want to
add 'Revoked' for example, later on.

--
Joan Wild
Microsoft Access MVP


  #3  
Old November 16th, 2004, 03:18 AM
John Vinson
external usenet poster
 
Posts: n/a
Default

On Mon, 15 Nov 2004 13:57:27 -0800, "el zorro"
wrote:

SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
(Thanks!)


If you reread the rant against Lookup Fields you'll see that it is NOT
objecting to using combo boxes (whether table based or list-of-values)
for entering data. It's perfectly routine to do so, and good
practice... ON FORMS, which is where data entry should be done.

In my opinion the worst disadvantage of Lookup Fields is that it keeps
people tied to using table datasheets for data entry, rather than
moving to Forms. Forms are much more capable and controllable than
table datasheets - and you can freely use combo boxes on Forms.

John W. Vinson[MVP]
Join the online Access Chats
Tuesday 11am EDT - Thursday 3:30pm EDT
http://community.compuserve.com/msdevapps
  #4  
Old November 16th, 2004, 02:38 PM
Roger Carlson
external usenet poster
 
Posts: n/a
Default

I don't like value lists either. Opinions vary, but it is just as easy to
store these values in a table. Then you can give your users a form in which
they can maintain their own dropdown lists. If they do not have this
option, they must come to me as the programmer to add it, because the
information is stored in the APPLICATION rather than in the DATABASE.
Personally, I think (and EF Codd agrees) that all data should be stored in
the database and not in the application.

--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/...UBED1=ACCESS-L

"el zorro" wrote in message
...
SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
(Thanks!)



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Troubleshooting Lookup Fields blaqkikapoo Database Design 2 August 9th, 2004 10:37 PM
Lookup fields on label report Howard Setting Up & Running Reports 1 June 3rd, 2004 02:43 AM
Make a field lookup dependent on the value in another field of a record? Susan A Database Design 8 May 22nd, 2004 09:10 PM


All times are GMT +1. The time now is 11:17 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.