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

Visit a strip club?

I think we can safely close this thread with the observation that we have
the "law enforcement" developers who want to protect their users from
themselves, and the "assume their adults and let their boss worry about the
children" developers.  As it happens I absolutely believe in protecting the
user from themselves, but not at the expense of preventing valid data entry.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of
DWUTKA at marlow.com
Sent: Tuesday, May 25, 2004 6:32 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various


I think JC is agreeing with me on this, and I think you have a disconnect on
what is a necessary limit, and what is an arbitrary limit.

255 characters is a necessary limit.  It is set by the fact that a text
field is defined to take up from 1 to 256 bytes. 1 byte is for the size
actually stored, the rest leaves up to 255 characters of space.  That is
built into Jet.  The only way around that limit is to either 'join' two or
more text fields together (which I have done on RARE occasions), or use a
Memo field.  Memo fields can hold quite a bit more, however, there are
drawbacks with Memo fields.  However, the line between when to use one or
the other is pretty clear.  Is the field in question a data point, or is it
a storage bin?  In other words, is the field going to represent one
particular fact?  If it is a single fact, yet it may go over 200 characters,
then either a second text field needs to be defined for carryover, or a memo
field should be used.

20 characters for an address field is an arbitrary limit.  An assumption is
made that no more then 20 characters is going to be used for that field.  It
is not a necessary limit.  You may set a textbox to a particular size, but
the textbox can be changed with little fuss.

Let's say you put gas in your car once a week.  Would you only put in the
amount you expect to use for the week, or would you completely fill your
tank?  If you only put in what you expect to use, if something UNEXPECTED
happens, you'll run out of gas, which is exactly what you do to your users
if you set arbitrary limits.  They'll be driving along, cruising down the
data entry highway, then they'll realize they need to take a detour.  Detour
is taken, and kaput, their system runs out of gas, so they have to call the
tow-truck developer to come give them more gas to get home.  If they go on
longer trips then what a normal car can hold, they need to buy a bigger gas
tank (or compress the data, and get a more efficient car).  You want to
provide your users with a full tank.  Filling the trunk with extra gas cans,
having a tanker drive beside them, or converting them to nuclear power is
going to be overkill, unless they want to run forever without refueling.
But that would be in the clients specs, wouldn't it?  If you give the users
a full tank, and the client expects them to only go 100 miles, if their
going off course to see their grandmother, or making trips to a strip club,
or whatever, that is the Clients responsibility to monitor their users, not
yours.

Drew

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


<<Might as well move them to a SQL server, that is hacked into every
computer system in the
world, to get as close to unlimited drive space.

You just made my point. There are limits, but your argument is "lets not
limit the data entry" because you somehow get burned on its size later.

I'm not being theatrical just realistic.