Re: database design for fast client updates
- From: "David Portas" <REMOVE_BEFORE_REPLYING_dportas@xxxxxxx>
- Date: 29 Mar 2006 05:43:39 -0800
T.H.N. wrote:
I'm trying to work out a database design to make it quicker for my client
program to read and display updates to the data set. Currently it reads in
the entire data set again after each change, which was acceptable when the
data set was small but now it's large enough to start causing noticable
delays. I've come up with a possible solution but am looking for others'
input on its suitability to the problem.
Use stored procedures for your updates, inserts, deletes and selects.
As far as I can see you aren't doing that now. Is there a reason why
not?
If you use procs then you won't need the triggers, you probably won't
need two tables and you'll probably see a performance improvement along
with all the other benefits of procs.
Thanks for including the DDL. Always tell us what version you are using
as well - it does help.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
.
- References:
- database design for fast client updates
- From: T . H . N .
- database design for fast client updates
- Prev by Date: database design for fast client updates
- Next by Date: 2005:how to find installed assemblies
- Previous by thread: database design for fast client updates
- Next by thread: Re: database design for fast client updates
- Index(es):
Relevant Pages
|