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

Scott Marcus marcus at tsstech.com
Wed May 26 06:16:33 CDT 2004


Francisco,

What you have said is exactly why I keep harping on the size issue. It isn't that the field can hold 255 characters, to me that is arbitrary. Well said...

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 Francisco H Tapia
Sent:	Tuesday, May 25, 2004 7:28 PM
To:	Access Developers discussion and problem solving
Subject:	Re: [AccessD] On DB Bloat, Bad DB Design, and various

DWUTKA at marlow.com wrote On 5/25/2004 3:32 PM:

>255 characters is a necessary limit.  
>  
>
How?

>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.  
>
>  
>
Storage, albeit nowadays cheap, is still and should continue to be a 
consideration for the lenght of a field.  A 20 Character address may be 
too small especially when I've ran len selects to grab the maximum size 
of an address field and have come up with: 53.  In Sql Server I can make 
my varchar field up to 8000 characters for this field but does it really 
make sense?, I can join and index it as well, but does it make sense to 
do so?

Both of you should heed that just because you can doesn't mean you 
"should".  Run a sample select on the existing data that your customers 
use, if their max LEN on the address field is 20 characters expand that 
by a few more as to give a tolarnce.  YOU WILL NEVER get it 100% perfect 
as far as lenghts are concerned. but limiting the amount of space will 
improve your storage needs.

Lastly, your Gas tank analogy is all wrong, Car makers put out various 
sizes of tanks for each car.  By your logic they'd be strapping your 
Ford Festiva w/ a Ford Expedition tank. 

<snip>

>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.  
>  
>
COMPUTER's are bound by limits.  There is only so much RAM, HDD, and 
SWAP space.  When the database grows beyond it's hdd space it must be 
transplanted to a bigger server, and eventually upsized to a bigger 
database (SQL Server for instance).

it's all limits.  If you really want to provide the most amount of space 
for your end users so they don't get limited, then why are you not 
working with mySQL or MS SQL databases so you CAN provide up to 8000 
characters per field.  HECK you never know they may want to write up the 
instructions on how to get to the location rather than the actual ADDRESS!

Not limiting fields is just plain careless!

-- 
-Francisco


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