Re: Lengthy recordset question

On Wed, 9 Jul 2003 09:14:28 -0500, "Dwayne Epps"
<dwayneepps (AT) centurytel (DOT) net> wrote:

I've built a simple ASP application that writes information submitted
through a HTML form to an Access database. Each recordset consists of 16
fields. It all works fine, but I was interested in getting opinions on
whether having a recordset that is 16 columns is too lengthy, and if so,
what is the downside? I know that there are benefits to using multiple
tables in a database, but wasn't sure if in this type of situation, it would
really matter? My next step is to create a page that will retrieve the
information from the database, display it on a page and enable the
administrator to print out the records and or delete them.

What you're talking about is what database geeks (no offense to
anyone) like to call "database normalization." A Google search on the
phrase "database normalization tutorial," it should turn up hundreds,
if not thousands, of pages where you can learn a bit more about it.
The short answer is that, whether or not it's too many, depends
entirely on the data.

The implications of a non-normalized data structure are that
duplicated data bloats the size of your database, data retrieval is
more complex and inefficient and that errors in the data are more
likely because of user error.

Also, I noticed when I was testing the app that the primary key (set to auto
increment) will still increment to the next numerical value even when I
delete the RS. So, for example I submit information and the database sets
to 1 (primary key) for the first recordset. I'll delete the recordset in
the database and then test again and the primary key is set to 2 even though
there is only one RS in the table. Is there a way to get the database to
set back to 1 when the RS's have been deleted out?
Any input is appreciated. Thanks.

You may be misunderstanding the purpose of a primary key. The primary
key's sole purpose is to positively identify a given record,
regardless of any data contained in that record. The actual value of
the primary key should be completely meaningless to the data. There
should be no reason to need to reset it and you should never display
it to the user. If users can see it, they'll find a reason to want to
modify it. Primary keys can be used to link related records. Imagine
what happens when you change one. ;-)


Gary