SQL Server database optimization for large database

Question

I am developing a website with huge data which to be stored in SQL Server database. How should I optimize it to make it faster. 1. Using Stored procedures. 2. Functions / Views. 3. Any other methods

Answer 1

Well, the most important thing would be to use appropriate indexes on your table that have large amounts of data stored in them.

You also might consider using partitioned tables.

Usind SPs or Views won't make your database faster.

Answer 2

Of course other methods 1) Optimization tables structure(if posible) 2) Optimal indexes structure(complicated indexes, included fields) 3) Partitioning(if server's a few physical disks) 4) SQL data compression (only Enterprise edition)

Answer 3

The most important thing to know in database tuning is how the data will be used.

Indexes can do wonders for increasing data retrieval speed. But over-indexing can create huge performance bottlenecks when writing data. (The indexes need to be updated as the data is written. This can, in the worst case, make your writes take several times as long as they would without the indexes.)

Likewise with views. A good indexed view can be a wonderful thing for performance and manageability if the data is largely read-only. But they can really drag a database down on writing.

Partitioning can be critical. If your data lives on a quality storage medium with lots of spindles, you can partition your data so that the most referenced data is spread across different spindles. That way you don't have read heads sitting idle while several requests are queued up on one drive.

Depending on your data access needs, it is also a popular ploy to setup multiple databases, only one of which can be written to. The others are all read-only copies. That way, you can query and analyze the data in an almost real-time fashion (if that is acceptable) and spread the load out across servers.

Finally, query tuning is very important. You can use the tools that come with SQL Server to help tune your query. Often, you don't even need an index to drastically improve read performance. You just need to alter your query to avoid unnecessary columns (that may rule out an existing index, for example) or unnecessary joins, sub-queries, etc.