Memo fields and performance/db corruption issues; best practices

What is the best practice for dealing with many input forms that
contain memo fields
to capture exceptions and extra information ( an audit trail or updates
field would be
one example) needed as an item moves through different processes. Note,
there are
some tables in which I have simply added a text field set to 255,
however, some of
these tables will have many edits and updates.

I thought about setting up some tables like this:

( tblMemos )
MemoID (Autonumber) 1-------( One Side)-----
Memo (Memo)

( tblItems )
ItemID
ItemDesc
MemoID >------(- to - Many Side )-----

well this is a fairly simplified version but you get the point...
right?
I also thought that this might hurt performance but that's a relative
statement
...and this may be a NULL issue given the power of modern PCs,
processors, and
network capacity (10/100/1000 cards, routers, and switches).

....or maybe I'm wrong?

Re: Memo fields and performance/db corruption issues; best practices

Memo fields should be used sparingly. If you truely need them, by all
means use them. Keep in mind you cannot index on memo fields.
Furthermore you cannot group on them in reports. Searches can be
lengthy as well. I have used them as audit trails and lengthy
descrition fields but again only where truly needed.

This is also true for text fields. If you need 255 characters then use
them. But, I have seen developers (amatuers?) that would create a
first name field, last name field and so and allow 255 characters each.
Then users start adding nick names and other crap in there as well. I
have even seen state field which should be limited to two characters
have 60 characters.

The main point is to limit what users can enter and do you need to
index.