RE: Database design question

First question, why limit this solution to notes about/by a user? You
know the next request will be "That's great, we want the same thing for
items"... "for vendors"... "for orders"... etc. I would consider the
primary key and try to abstract away the user concept, perhaps a simple
50-byte character field, in the current case it could contain
"user-<username>", so qsecofr notes would be "user-qsecofr", but then
when the want it for items you could use the same exact programs and
tables, with a high-order key of "item-12345"... you get the idea. We do
this in a number of systems, but we've gotten to the point that all our
tables have a GUID on them, so we can use the guid as the high-order
key. We call it the "OwningRowGUID" (actually we've moved onto OIDs, but
that's another post)

As for the length of the note, just make it as large a possible, I'd
recommend a CLOB. No matter what the solution you use, the users will
always want it larger. We started w/an 8K note (max in-line in
sqlserver) and users started cutting/pasting word documents into the
notes. I'd just say screw-it and make it the largest possible. As for
the performance differences between the different allocate options, I
think you'll find the performance choke-point isn't retrieving the note,
but sending it down the pipe.

Finally, do they want plain-text notes, or should you be looking at
implementing some sort of rich editor so they can
bold/underline/indent/bullet/etc.

-Walden