Làm thế nào nvarchar (tối đa) lưu trữ dữ liệu trong cơ sở dữ liệu sẽ nhanh như vậy nếu một số dữ liệu ít hơn 4000 ký tự?


8

Tôi phải phát triển một CMS sẽ hỗ trợ hai ngôn ngữ tiếng Anh, tiếng Ả Rập. CMS này sẽ là một loại trang web xuất bản bài viết. Trong khi thiết kế và phân tích tôi thấy rằng một số bài viết có độ dài hơn 8000 ký tự. Bảng của tôi có một số cột như

PageID int,
PageTitleEnglish nvarchar(200),
PageTitleArabic nvarchar(200),
PageDescEnglish nvarchar(500),
PageDescArabic nvarchar(500),
PageBodyEnglish nvarchar(max)
PageBodyArabic nvarchar(max)

Nếu tôi giữ PageBody là nvarchar (4000) thì tôi bị giới hạn ở 4000 ký tự và nếu tôi phải lưu trữ phiên bản tiếng Ả Rập thì tôi cần 16000 byte (Vì tiếng Ả Rập là Unicode và mất thêm 3 lần dung lượng thì ASCII).

Vì vậy, tôi chỉ còn lại tùy chọn xác định PageBody là nVarchar (max) , Điều này sẽ có nhược điểm từ quan điểm hiệu suất. Câu hỏi thực tế của tôi là nếu một số dữ liệu trong cột PageBody có ít hơn 4000 ký tự thì MS SQL Store sẽ thay vì dữ liệu trong cột nội tuyến hoặc riêng biệt trong cơ sở dữ liệu.

Tôi cũng đã tìm kiếm điều này trên Google nhưng không tìm thấy câu trả lời nào phù hợp và làm thế nào tôi có thể cải thiện hiệu suất trong kịch bản như vậy.

Mọi đề xuất cho thực tiễn tốt nhất cho thiết kế CMS đa ngôn ngữ như vậy đều được chào đón.

Tôi chỉ cần hỗ trợ hai ngôn ngữ Ả Rập và tiếng Anh


Bạn sẽ luôn có tiếng Anh và tiếng Ả Rập? Hoặc có thể chỉ là một tùy chọn? Nếu vậy, một luôn luôn là bắt buộc? Bạn có mong đợi nhiều ngôn ngữ sau này không?
gbn

Câu trả lời:


9

Một nvarchar(max)giá trị sẽ được lưu trữ " liên tiếp " nếu nó đủ ngắn.

Hành vi mặc định có thể được sửa đổi bằng cách sử dụng tùy chọn sp_tableoption , "loại giá trị lớn ngoài hàng". Tôi sẽ không làm phiền. Công cụ DB sẽ tự quản lý điều này một cách hiệu quả.

Đối với thiết kế, có một số cách để làm điều này dựa trên mô hình của bạn:

  • Bạn sẽ luôn có cả tiếng Anh và tiếng Ả Rập?
  • Một người có thể là tùy chọn? Nếu vậy, một luôn luôn là bắt buộc?
  • Bạn có mong đợi nhiều ngôn ngữ sau này không?

1. Bảng riêng

Đó là, bạn có thể tách các ngôn ngữ riêng biệt thành các bảng khác nhau.
Điều này cho phép đối chiếu mức bảng chứ không phải là mức cột

Nó cho phép nhiều hàng hơn trên mỗi trang và có nhiều cơ hội lưu trữ LOB liên tiếp hơn

Trang

  • Trang ID
  • TrangOtherInfo ...

PageEnglish (lưu ý varchar có thể ổn ở đây)

  • Trang ID
  • PageTitleEnglish varchar (200),
  • Trang vares TrangEescEnglish (500),
  • PageBodyEnglish varchar (tối đa)

TrangArabic

  • Trang ID
  • PageTitleArabic nvarchar (200),
  • TrangDescArabic nvarchar (500),
  • TrangBodyArabic nvarchar (tối đa)

2. Hàng riêng biệt

Hoặc có một cột ngôn ngữ để hỗ trợ một số ngôn ngữ.
Điều này có nhược điểm là đối chiếu sẽ được sửa cho tất cả các ngôn ngữ có nghĩa là sắp xếp / lọc kém

Trang

  • Trang ID
  • PageOtherInfo ..

Trang

  • Trang ID
  • Mật ngữ,
  • Trang tiêu đề nvarchar (200),
  • TrangDesc nvarchar (500),
  • PageBody nvarchar (tối đa)

4
  • MS SQL Server có kích thước trang cố định là 8KB.
  • Một hàng không bao giờ được chia trên nhiều trang, nhưng một số hàng có thể chia sẻ một trang.
  • Tuy nhiên, nvarchar (tối đa) và dữ liệu BLOB khác có thể được lưu trữ bên ngoài hàng / trang.

Điều này có nghĩa là để mọi thứ vừa với một hàng, tổng của tất cả các kích thước phải nhỏ hơn 8K. Nếu không, SQL Server sẽ lưu trữ các BLOB bên ngoài hàng / trang.

Là số lượng dữ liệu lớn đến mức điều này thực sự gây ra một vấn đề hiệu suất?

Như một tùy chọn khác, có lẽ bạn có thể thay đổi cấu trúc dữ liệu của mình để có các hàng riêng biệt cho các trang tiếng Anh và tiếng Ả Rập và bao gồm một cột mã ngôn ngữ thay thế. Sau đó, bạn sẽ không phải phù hợp với cả tiếng Anh và văn bản tiếng Ả Rập trong cùng một hàng và điều đó cũng có ý nghĩa khi tìm nạp dữ liệu, vì có lẽ bạn sẽ không cần phải tải tiếng Anh và tiếng Ả Rập cùng một lúc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.