在SQL Server中存储大数据的最佳方法

Question

I have a news website created with ASP.NET MVC.

Below is my table:

CREATE TABLE [dbo].[News] (
[NewsID]         INT            IDENTITY (1, 1) NOT NULL,
[InstitutionID]  INT            NOT NULL,
[Title]          NVARCHAR (450) NOT NULL,
[NewsDate]       DATETIME       NOT NULL,
[Description]    NVARCHAR (MAX) NULL,
[path]           NVARCHAR (MAX) NULL,
[PostedBy]       NVARCHAR (MAX) NULL,
[ContactPhone]   NVARCHAR (MAX) NULL,
[ContactEmail]   NVARCHAR (MAX) NULL,
[NewsExpiryDate] DATETIME       NOT NULL,
CONSTRAINT [PK_dbo.News] PRIMARY KEY CLUSTERED ([NewsID] ASC),
CONSTRAINT [FK_dbo.News_dbo.state_InstitutionID] FOREIGN KEY ([InstitutionID]) REFERENCES [dbo].[state] ([InstitutionID]) ON DELETE CASCADE );

I noticed that my database has increased to 8GB, and it is getting slower to load a page.

I am thinking of storing the news in a file and then saving the path in database.

Is there anyway I can convert the form value representing "[Description]" into a file and then store the path to my database?

Answer 1

Certainly you can store files locally and then 'link' to them in the database. But that approach is probably the wrong one if your application and database are not on the same server (the database server should be optimized for file storage, and that's where files should go). First, You lose all querying and indexing possibilities if you store your Description field off-db. Second, the database server "should" be powerful enough for this task. You should look into tuning the database engine and server.

Let's assume you've done all that. You need to make sure your application (the thing connecting to the db) can write and read these files. You probably need to set up a top-level directory that has plenty of space. You should pay attention to permissions/security -- who can read/write these files. Finally, you need a scheme of storing files and creating these files. A typical scheme is to convert the description to a hash (md5 would be OK here, sha256 would be best) and use the hash as the filename. You chop of the filename so that it contains 2 or 3 levels of directories (large directories often slow some systems down): So ab2442vc25 becomes a/b2/442vc25 . Store your description there and store the path name in Description_path . Keep Description null in those cases.

But I'm skeptical this will actually help.

Answer 2

As John Saunders stated in the comments, you misuse nvarchar(max) . If the Title can be stored in 450 chars, the ContactPhone can certainly be stored in less then 20. the PostedBy and Email also can be truncated to a more appropriate size, and I'm guessing the path also should not be over a 100 chars at most.
Also, If possible, I would probably move the PostedBy , ContactPhone and ContactEmail to a new table (I would probably call it NewsAuthors ) and replace them in the News table by a foreign key to this table. This have the potential to save you a lot of storage space.

As to performance, storage size is usually not the problem, as NotMe suggested in the comments.
You can probably improve performance dramatically by using proper queries and indexes on your database.

A good place to start is running your most frequent queries directly on SSMS and view the execution plan. sql server may suggest creating indexes. if it does, create them.