Re: SQL2000/ASP.Net performance question
From: Rocky Moore (gRockyMoore_at_hintsandtips.com)
Date: 08/15/04
- Next message: Rocky Moore: "Performance and Bit fields.."
- Previous message: John Bell: "Re: Resettin Running Total"
- In reply to: Bill Cohagan: "SQL2000/ASP.Net performance question"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 15 Aug 2004 03:24:39 -0700
"Bill Cohagan" <bill@teraXNOSPAMXquest.com> wrote in message
news:uRIu9gOgEHA.2468@TK2MSFTNGP12.phx.gbl...
> I'm building an ASP.Net app that will process a web form containing a few
> hundred (~300) fields, the results going into a SQL database. Each field
> from the web form will generate a record in a single table in the
database.
> I've got to be able to handle a few hundred users submitting these forms
at
> "the same time".
>
> Given my current data layer I'm connecting to the database for each record
> added to the table. What I'm wondering about is whether this will cause
> performance problems given the loads I anticipate. Another alternative is
to
> connect to the database only once per form, inserting all the new records
> using that single connection. This would require modifying the data layer
> which isn't a huge problem, but I'd rather not bother if it isn't a
problem
> doing it the "easy" way. Although this reduces the number of connections,
> it'd keep those connections around longer -- perhaps causing locking
> problems?
>
> I'm a relative newbie at this so feel free to point me to sources where I
> might learn more about these issues. Of course, just explaining the
> tradeoffs would be OK too!
>
> Thanks in advance,
> Bill
Recently I built sites for a company that handles insurance quotes for
insurance companies. The forms were comprised of 100-200 fields. Most of
the 90% of the fields were never used in queries other than to store and
print. In this case, I build a field manager that took the data stored in
the controls on the form and placed them into a hash table based on the
field name. Inside the application it would simply pull the values or set
values in its computations inside this hash table. When the quote would be
saved, the key fields that it did need to query were stored in a single
record. Then all fields were serialized into a blob and stored with the
record. This made it easy in the application to read/write all those fields
in one pass while still exposing fields that need to be queried in the same
record. Worked really slick. When a field was added or removed, I only had
to change the field on the form and everything still linked up.
The field manager also handled basic validation as the first letter of the
control name for a field on the form would start with an 'R" if it was a
required field and then the next few letters would be the type of data (such
as ddl for a drop down list, dbl for a double value, etc). The rest of the
letters of the control name were the field name it would be stored in the
hash table under.
This only works if most of the fields are not used in SQL queries.
-- Rocky Moore www.HintsAndTips.com / Share your tips - Earn rewards www.MyQuickPoll.com / 2004 Election poll ID #33 www.GotTheAnswerToSpam.com / Block virtually all spam email www.RJSoft.com/Products/RJContentPanel/ - Free web user template content control!
- Next message: Rocky Moore: "Performance and Bit fields.."
- Previous message: John Bell: "Re: Resettin Running Total"
- In reply to: Bill Cohagan: "SQL2000/ASP.Net performance question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
