bagaimana nvarchar (max) akan menyimpan data dalam basis data apakah akan cepat jika beberapa data kurang dari 4000 karakter?


8

Saya harus mengembangkan CMS yang akan mendukung dua Bahasa Inggris, Arab. CMS ini akan menjadi semacam situs Penerbitan Artikel. Saat mendesain & menganalisis saya menemukan bahwa beberapa artikel panjangnya lebih dari 8000 karakter. Meja saya memiliki beberapa kolom sebagai

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

Jika saya menjaga PageBody sebagai nvarchar (4000) maka ia terbatas pada 4000 karakter dan jika saya harus menyimpan versi Arab maka saya perlu 16000 byte (Karena Arab adalah Unicode dan membutuhkan 3 kali lebih banyak ruang daripada ASCII).

Jadi saya hanya punya pilihan untuk mendefinisikan PageBody sebagai nVarchar (maks) , ini akan menurunkannya dari sudut pandang kinerja. Pertanyaan saya yang sebenarnya adalah jika beberapa data dalam kolom PageBody kurang dari 4000 karakter, apakah itu MS SQL Store daripada data dalam kolom inline atau secara terpisah dalam database.

Saya mencari ini di Google juga tetapi tidak menemukan jawaban yang relevan dan bagaimana saya dapat meningkatkan kinerja dalam skenario seperti itu.

Setiap saran untuk praktik terbaik untuk desain CMS multibahasa seperti itu disambut baik.

Saya perlu Mendukung Hanya dua bahasa Arab & Inggris


Apakah Anda akan selalu memiliki bahasa Inggris dan Arab? Atau mungkin hanya satu opsional? Jika demikian, apakah seseorang akan selalu wajib? Apakah Anda mengharapkan lebih banyak bahasa nanti?
gbn

Jawaban:


9

Sebuah nvarchar(max)nilai akan disimpan " di baris " jika cukup singkat.

Perilaku default dapat dimodifikasi menggunakan opsi sp_tableoption , "tipe nilai besar di luar baris". Saya tidak akan repot. Mesin DB akan mengelola ini secara efisien dengan sendirinya.

Adapun desain, ada beberapa cara untuk melakukan ini berdasarkan pada model Anda:

  • Apakah Anda akan selalu memiliki bahasa Inggris dan Arab?
  • Bisakah satu opsional? Jika demikian, apakah seseorang akan selalu wajib?
  • Apakah Anda mengharapkan lebih banyak bahasa nanti?

1. Tabel terpisah

Artinya, Anda dapat memisahkan bahasa yang terpisah ke dalam tabel yang berbeda.
Ini memungkinkan pengumpulan tingkat tabel daripada yang tingkat kolom

Hal ini memungkinkan lebih banyak baris per halaman dan lebih banyak peluang penyimpanan LOB in-row

PageParent

  • PageID int,
  • PageOtherInfo ...

PageEnglish (note varchar mungkin OK di sini)

  • PageID int,
  • PageTitleEnglish varchar (200),
  • PageDescEnglish varchar (500),
  • PageBodyEnglish varchar (maks)

PageArabic

  • PageID int,
  • PageTitleArabic nvarchar (200),
  • PageDescArabic nvarchar (500),
  • PageBodyArabic nvarchar (maks)

2. Baris terpisah

Atau memiliki kolom languageID untuk mendukung beberapa bahasa.
Ini memiliki kekurangan bahwa collation akan diperbaiki untuk semua bahasa yang berarti penyortiran / penyaringan yang buruk

PageParent

  • PageID int,
  • PageOtherInfo ..

Halaman

  • PageID int,
  • Kode Bahasa,
  • PageTitle nvarchar (200),
  • PageDesc nvarchar (500),
  • PageBody nvarchar (maks)

4
  • MS SQL Server memiliki ukuran halaman tetap 8KB.
  • Baris tidak pernah terpecah pada beberapa halaman, tetapi beberapa baris dapat berbagi satu halaman.
  • nvarchar (maks) dan data BLOB lainnya dapat disimpan di luar baris / halaman.

Ini berarti bahwa untuk semuanya agar sesuai dalam satu baris, jumlah semua ukuran harus kurang dari 8K. Jika tidak, SQL Server akan menyimpan BLOB di luar baris / halaman.

Apakah jumlah data begitu besar sehingga ini benar-benar menyebabkan masalah kinerja?

Sebagai pilihan lain, Anda mungkin bisa mengubah struktur basis data Anda untuk memiliki baris terpisah untuk halaman bahasa Inggris dan Arab, dan sebagai gantinya menyertakan kolom kode bahasa. Maka Anda tidak harus mencocokkan teks bahasa Inggris dan Arab di baris yang sama, dan itu juga masuk akal ketika mengambil data, karena Anda mungkin tidak perlu mengambil bahasa Inggris dan Arab pada saat yang sama.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.