Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 To Store Millieans of Records in SQl Server Database

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2004-07-08 : 12:07:31
Sanjay Rawat writes "what should be the necessary steps (right from designing and table creation) for storing the millians
of records in a sql server table so that i can easily search the
record from an asp page."

drymchaser
Aged Yak Warrior

552 Posts

Posted - 2004-07-08 : 12:27:50
I'm sorry if this sounds crass.

Hire/contract a SQL Developer/DBA.

Because if you're asking this question on an internet message board. You need a lot of help. There are "millions" of answers for that question.
Go to Top of Page

derrickleggett
Pointy Haired Yak DBA

4184 Posts

Posted - 2004-07-08 : 13:10:54
Lots of memory, a big disk subsystem, good indexes, smart design to keep rows/page small and eliminate unnecessary data. This is just hitting the tip of the iceberg. You really do need to get a DBA to look at your design, especially for the "easily search" part if you want it to return in any decent amount of time.

MeanOldDBA
derrickleggett@hotmail.com

When life gives you a lemon, fire the DBA.
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2004-07-08 : 13:38:22
How many millions of rows? in how many tables?

And how many NEW and UPDATED rows per hour?

And how many QUERY per hour?

If may be if there are not too many millions! and not too many updates, and not too many Queries, that a SQL table with not too much optimisation will just make mincemeat of the job.

I'm embarassed to say that we have a logging table itching to be optimised. Currently it has 10,971,205 rows with 208,092 inserts in the last day and 68,085 updates.

The number of queries is very low, but it has indexes on the two main columns that interact with queries, plus a PK.

Table scan is 32 seconds, and clustered/non-clustered index operations are "instant"

So I don't think the table is particularly optimal, but it copes just fine ...

Kristen
Go to Top of Page
   

- Advertisement -