Will ASP query be slow if field names are lengthy?

[ynott]

I have an Access database with 58 fields in one table. I wrote many
of the field names so that they were descriptive so that others could
figure it out in the future. As an example, one field name is called
MissingPart14990aDescribe.

Should I be worried about the length of the field name? I'm expecting
about 20,000 records a year to be entered into the database. So, five
years from now, which would be about 100,000 records, will the
query.asp for a list of records be slow due to field name size? BTW,
the query.asp would just show a list of the last 3 months worth of
records and only a snapshot of about 6 of the 58 fields.

TIA

 

[Lasse Edsvik]

ynott,

Its a very bad idea to add extra columns just for description, Just create a
readme.txt instead were you describe your tables. Else you'll end up with a
really big database with unnecessary information.

columns, not fields.....

Never list more than 100 in a page...... use paging if needed...... and if
your database is going to be that large you might consider using SQL Server
instead.

/Lasse

 

[Evertjan.]

Lasse Edsvik wrote on 07 dec 2004 in
microsoft.public.inetserver.asp.general:

Its a very bad idea to add extra columns just for description, Just
create a readme.txt instead were you describe your tables. Else you'll
end up with a really big database with unnecessary information.

columns, not fields.....

Never list more than 100 in a page...... use paging if needed......
and if your database is going to be that large you might consider
using SQL Server instead.

[This is what happens with topposting:

ununderstandable answers, because you have to scroll down for the
individual questions again and again.

Please use interposting on usenet.]

Records have fields, HTMLtables have rows and columns, Database tables
are a random collection of records, and because of the randomness the
records shouldn't be called rows.

 

[Bob Barrows [MVP]]

Records have fields, HTMLtables have rows and columns, Database tables
are a random collection of records, and because of the randomness the
records shouldn't be called rows.

LOL
Try running that statement by Joe Celko and see what happens.

Bob Barrows
PS. You've got it backwards Evertjan.

 

[Bob Barrows [MVP]]

I have an Access database with 58 fields in one table. I wrote many
of the field names so that they were descriptive so that others could
figure it out in the future. As an example, one field name is called
MissingPart14990aDescribe.

Should I be worried about the length of the field name? I'm expecting
about 20,000 records a year to be entered into the database. So, five
years from now, which would be about 100,000 records, will the
query.asp for a list of records be slow due to field name size? BTW,
the query.asp would just show a list of the last 3 months worth of
records and only a snapshot of about 6 of the 58 fields.

TIA

No, the length of the field names should have nothing to do with the speed
of a query. You are increasing the size of the metadata (the description of
the data, technically: "data about data"), which will increase the amount of
network traffic and the amount of resources used to create the recordset to
contain this data. But this will not be dependant on the number of rows in
your table, and with proper bandwidth and good programming techniques, will
not be likely to cause any performance problems.

I'm more concerned about the possibility of bad database design here. What
is the meaning of the "14990a"? It makes it appear as if you are storing
data in your metadata: never a good idea.

Bob Barrows

 

[Lasse Edsvik]

Bob,

LOL, agree....

report him missing if he doesnt post any more on this newsgroup lol

 

[Evertjan.]

Bob Barrows [MVP] wrote on 07 dec 2004 in
microsoft.public.inetserver.asp.general:

Bob Barrows
PS. You've got it backwards Evertjan.

Bob, I am not going to play the "I am right, you are wrong" game.

Evertjan.

P.S.:
I am right, as long as we are talking 4th generation datavases:

The word "row" implies order. [btw: as do "columns"]
If there are rows, there must be a front row and a back row.

Records can be thrown into a container and can and will
loose order in the process. The order should always be defined, like
alphabetical, birthdate or geographical. There is no default order in a
collection of records. [btw: as do "fields"]
This order is only an apparent order, a view. There can be many views.

Rows can be seen as ordered units of a stack,
records as random units of a collection named database table.

Columns can be seen as ordered units of a row,
fields as random units of a collection named record.

 

[Bob Barrows [MVP]]

Bob Barrows [MVP] wrote on 07 dec 2004 in
microsoft.public.inetserver.asp.general:


Bob, I am not going to play the "I am right, you are wrong" game.

Evertjan.

P.S.:
I am right, as long as we are talking 4th generation datavases:
LOL

I used "LOL" in my initial reply because I really don't care. I understand
what's being talked about regardless of whether "row" or "record", or
"column" or "field" is used. If you want to argue about this, go find Celko
or Pascal on any of the innumerable newgroups that they frequent.

Bob Barrows

 

[Mike Brind]

No, the length of the field names should have nothing to do with the speed
of a query. You are increasing the size of the metadata (the description of
the data, technically: "data about data"), which will increase the amount of
network traffic and the amount of resources used to create the recordset to
contain this data. But this will not be dependant on the number of rows in
your table, and with proper bandwidth and good programming techniques, will
not be likely to cause any performance problems.

I'm more concerned about the possibility of bad database design here. What
is the meaning of the "14990a"? It makes it appear as if you are storing
data in your metadata: never a good idea.

Bob Barrows

I agree. 58 fields in one table is not a good idea either. It suggests
a lack of normalisation. How many other tables are there in the database?

Mike Brind

 

[Paul Baker [MVP, Windows - SDK]]

It is generally recommended that you do not use Jet in a multi-threaded
production enviroment such as a web server. This is particularly important
if you have a lot of records and users.

Paul

 

[Bob Barrows [MVP]]

Maybe so, but it is done.Good programming practices (avoidance of dynamic
sql, minimizing database connection duration, proper utilization of ADO
objects, proper use of indexes, etc.) can make Jet much more scalable than
it is commonly given credit for.

Of course, a breaking point can be reached (the number of records really
isn't relevant: it's the number of users that can kill you) where you need
to switch to a server-based database to achieve scalability goals.

Having said that, I will say that I prefer using SQL Server for many
reasons.

Bob Barrows