[AccessD] On DB Bloat, Bad DB Design, and various

Scott Marcus marcus at tsstech.com
Tue May 25 06:37:58 CDT 2004


<< Just today I had to go in and remove a mask that the client requested.  When
I designed the db the client swore up and down that they would NEVER have
claimants residing outside the US.  They did NOT want a country field, they
wanted a US state table etc.  I explained the obvious and gave them what
they asked for.  Today I removed the zip code mask so that a Canadian zip
could be entered.  The 2nd line of the address is being used for the city
and country.

Why is it such a big deal to go and make the change? That's why they pay you. What if the maximum for a text field was 512? Would you then set the limit to 512? 

Scott Marcus
TSS Technologies, Inc.
marcus at tsstech.com
(513) 772-7000

 -----Original Message-----
From: 	accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]  On Behalf Of John W. Colby
Sent:	Monday, May 24, 2004 8:59 PM
To:	Access Developers discussion and problem solving
Subject:	RE: [AccessD] On DB Bloat, Bad DB Design, and various

Brett,

>If you always allow 255 characters for your text fields, do you format your
forms and reports to display that size of data?

I format forms to accept as much as is normally needed plus some, taking in
to account screen real estate.  You can always scroll left / right or even
add scroll bars to text boxes to allow vertical scrolling as needed.  In
reports I use AllowToGrow so that the box can expand vertically as needed.

>Of course, I'm assuming that you don't display all 255 characters.

On forms that is obviously true, on reports it is false.

>Have you ever encountered users that misuse the fields?

Of course.

>Doesn't allowing the entry of 255 characters in any text field (say Address
2) invite the careless user to treat it as the Memo field they forgot to ask
for?

Yes.

OTOH, how do you handle it?  OK, lets not make it 255, let's make it
what.... 25?  What happens when they really do need 26?  OK, if not 25, then
what?  50?  You are making an arbitrary decision, running the risk of a
valid address not fitting (and I've seen some pretty big ones) or, if you
expand to 50, then allowing the user a short memo anyway.

I cannot set the rules for the user, the client needs to do that.  If the
client does not want the user using Address2 as a memo field they need to
state that.  If the user uses Address2 as a memo field then the client needs
to discipline their employee.  My job is to allow the user to capture the
data, whatever that data might be.  My job is NOT to tell the user "make it
fit in 20 spaces".

IF the client asks me to set up a zip code mask, or a phone mask or whatever
I will do so.  That is the CLIENT requesting it.  If the client requests
that I set Address2 to 20 characters then I will do so, because the CLIENT
asks me to.  I will state the argument that the address might be longer than
20, explain that in the event they encounter an address longer than the
limit they will have to get all the users out of the db (or at least out of
that table) in order to modify things so that the address fits.  If they
want 20, then they get 20 but I am never going to arbitrarily make such a
decision.  If the data MUST be limited, or checked in some way, for a valid
business rules reason, I will do that.  But that is fundamentally different
from arbitrarily "deciding" on 20 (or whatever) characters.  I certainly do
not agree that it is sloppy programming (db design).

Just today I had to go in and remove a mask that the client requested.  When
I designed the db the client swore up and down that they would NEVER have
claimants residing outside the US.  They did NOT want a country field, they
wanted a US state table etc.  I explained the obvious and gave them what
they asked for.  Today I removed the zip code mask so that a Canadian zip
could be entered.  The 2nd line of the address is being used for the city
and country.

I explained the obvious and was explicitly told NOT to give them what they
ultimately needed.  No way in hell I am going to INTENTIONALLY not give them
what they need just because I personally think an address should fit in 25
(or whatever) characters.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Brett Barabash
Sent: Monday, May 24, 2004 1:22 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


I've been watching this thread for a while now, and need to ask this
question to Drew and JC:

If you always allow 255 characters for your text fields, do you format your
forms and reports to display that size of data?

Drew, you talk about being "burned by these limitations".  It would seem to
me that if your report's fields are not wide enough and truncate the field
contents, you have effectively imposed that limitation.  However, you have
done it in a much more insidious way, by allowing the user to type in a long
string and then not displaying its full contents in the output.  This
seriously breaks one of my cardinal design rules of accepting user input
that the system is not able to process.

Of course, I'm assuming that you don't display all 255 characters.  If my
assumption is wrong and you actually do leave enough room for all 255,
doesn't this result in pretty weird looking tabular reports?  How many 255
character fields can you fit across an 8 1/2 X 11" piece of paper?  1?  2
perhaps?

Have you ever encountered users that misuse the fields?  I have (in almost
every company I've worked for).  Doesn't allowing the entry of 255
characters in any text field (say Address 2) invite the careless user to
treat it as the Memo field they forgot to ask for?

Seems like sloppy programming to me.  And very surprising comments from
developers who preach about following good data modeling practices.


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com]
Sent: Friday, May 21, 2004 1:54 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


I think we are talking apples and oranges here.  Yes, the page file size
needs to be taken into consideration.  I set all of my text fields to 255. I
do this because I don't want to be backed into a wall, because I set a size
limit that prevents a user from entering what they need to enter.  If I
provide a phone number field, and set it to 10 (area code and phone number),
sure, I am 'limiting' the client.  However, what happens when they want to
put in an international number.  Or if the US decides to move to 8 digit
phone numbers.  Who knows, there are all sorts of reasons that the field
size may change.  Now, if I have some sort of logic checking data integrity,
that would have to be changed, but if I don't, by having the field size set
to 10, I am limiting the users at the table level, to a point where they
cannot do their job.  If I have it set to 255, I am 99.99999% they would
never put 255 characters into that field, but they may put in 11, or 12,
etc.

Oh well, this really isnt' something I feel like arguing about.  I see your
point Jürgen, but this is really a case of who has been burned and how.  I
have been burned over and over by previous developers putting such
limitations into their databases.  I have never been burned by the page file
size.  In fact, I completely forgot that the limit even existed, until it
popped up on the list a few weeks ago.  So that is why I set my default text
field size to 255.

Drew


----------------------------------------------------------------------------
----------------------------------------
The information in this email may contain confidential information that
is legally privileged. The information is only for the use of the intended
recipient(s) named above. If you are not the intended recipient(s), you
are hereby notified that any disclosure, copying, distribution, or the
taking
of any action in regard to the content of this email is strictly prohibited.
If
transmission is incorrect, unclear, or incomplete, please notify the sender
immediately. The authorized recipient(s) of this information is/are
prohibited
from disclosing this information to any other party and is/are required to
destroy the information after its stated need has been fulfilled.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is performed by SurfControl E-mail Filter software
in conjunction with virus detection software.

--
_______________________________________________
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







More information about the AccessD mailing list