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

Good points, but in 99% of the stuff I deal with, they don't apply.  I build
mostly ASP interfaces.  In this particular case, the data was now in SQL
server, so db size is neglible.  That was the case even in Access.  They do
have a SLOW SQL server though.  Since the interface (for both data entry and
reporting) is in ASP, the HTML doesn't care how long the data is, it's in an
HTML table, and there is never an issue of getting stuff cut off.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus
Sent: Thursday, May 27, 2004 4:29 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


On the flip side, Drew.

If the client had the field size set to the max and was only using a very
small portion of that max and then suddenly started using a large portion of
that field(because a business rule changed), you may have problems with
complex reports that take way more than 1 & 1/2 hours to fix. You may also
have other issues, like database growth that wasn't planned for. I know I'm
reaching, just curious.

One abuse I can think of was a client that started putting in Husband and
Wife names into the firstname field (that I set at 50 characters). This
caused mailing and invoice problems as well as office confusion. Sure, you
may say that this is a training issue, but they did it because it worked
around a new business requirement that the program lacked. In most cases,
their work around didn't cause a problem. When it did cause a problem guess
who got the blame? The client only calls when there are problems. It doesn't
matter if it's a field being too small or too big.

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