DWUTKA at marlow.com
DWUTKA at marlow.com
Fri Mar 26 10:38:32 CST 2004
Actually agree with you on the user issue. A well designed data structure is usually worse then greek to an end user. It wasn't your comment I was talking about though. Let me ask you a question though, because you and I have agreed on a lot of other things before, so I'm a little shocked on your position on this. If you have an Address table, (for US clients....for this example), and you want to get the two letter state abbreviation, do you simply give them a textbox, or do you give them a combo that builds itself from a 'State' table? I go with the state table. And since I may have multiple forms based on that table, I usually use a Lookup field, so that when I build the form, that combo is predefined. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Francisco H Tapia Sent: Friday, March 26, 2004 1:36 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Framework Discussion - set up question DWUTKA at marlow.com said the following on 3/25/2004 1:58 PM: > Okay, for number one, let's drop that. It's a pointless argument. If you > want to argue that using Lookups adds confusion, then I would REALLY hate to > see your table designs. Have you ever tried to explain a many to many table > to a 'user'? Trust me, they'll pick up what a 'lookup' field does a LOT > faster. And if you aren't using things like many to many tables, because > users could get confused, then you are not normalizing your data. See how > this is a BAD argument to try to defend against? I'll ask this because you brought it up, but how is my comment any indication of any lack of normalization on my database design? I'll tell you... it has NO BEARING on my database design. I don't care when a user is confused about database design. I don't explain to my users about lookup tables, that's not my job. I also don't try to explain Boyce-Codd 3rd Normal form. These are very dry and pointless topics to bring up w/ your users... I also don't particularly approve of allowing end users to write their own ad-hoc queries for that matter.. this is because they can join something so badly that it causes unnecessary page locks and system performance overall. If you do, then to each their own. Where I'm working at now, it has been now long accepted that certain users will write their own queries... that has all stopped w/ our recent upgrade to SqlServer2000. I've blocked all direct access to tables and many views. all they are allowed to do is run sprocs (Stored Procedures). So what? why should I expalin the concept of a temporary table to my end users? or how to use a server sided cursor? hmm? I don't care what confuses them about database design. It would be diffrent if they were underlings and I had to make sure they were up to speed so they could take over the project... they are not.. they are users of my and my co-worker's database system. That's not to say I don't appreciate or even give out helpful tips for those that are learing.. but I won't have them break down a system I'm responsible for. Lastly... I DO work on a plethora of databases.. and on occasion I do take in contract work (tho not lately). Adding Lookup tables adds a level of non-sense imnsho. Sure they're great if I only worked on a handful of db's. And it's not like I can't figure out what the previous developer did... you see... there is a bit of un-needed confusion.... > Now for number 2. You can't hack a feature with a 'feature creep' agrument. > Feature creep can affect anything in a bad way, however, if you are getting > paid by the hour, or are doing contract work, Feature creep means more > money! LOL well to each their own I guess :| -- -Francisco -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com