Apa konsekuensi dari pengaturan varchar (8000)?

22

Karena varchar mengambil ruang disk sebanding dengan ukuran bidang, apakah ada alasan mengapa kita tidak harus selalu mendefinisikan varchar sebagai maksimum, misalnya varchar(8000)pada SQL Server?

Pada membuat tabel, jika saya melihat ada yang melakukan varchar(100)saya harus memberi tahu mereka tidak Anda salah Anda harus lakukan varchar(8000)?

sql-server varchar

— Aleksandr Levchuk
sumber

Saya pikir kita harus membedakan di sini antara digunakan di buat tabel dan gunakan dalam deklarasi parameter prosedur tersimpan. Untuk interpretasi kedua lihat pertanyaan saya dba.stackexchange.com/questions/1772/…

— bernd_k

18

Panjang adalah kendala pada data (seperti PERIKSA, FK, NULL dll)
Performa saat baris melebihi 8.060 byte
Tidak dapat memiliki batasan atau indeks unik (lebar kolom kunci harus <900)
Standarnya adalah SET ANSI PADDING ON = potensial untuk banyak spasi tambahan yang akan disimpan
SQL Server akan menganggap panjang rata-rata adalah 4000 untuk operasi sortir, mengalokasikan memori berdasarkan ini (perlu menemukan tautan untuk mendukung ini tetapi membuat saya berkarat sementara saya melakukannya :-)

Ringkasan: jangan lakukan itu.

— gbn
sumber

Performa saat baris melebihi 8.060 byte . Itu mengacu pada byte yang digunakan sebenarnya dan bukan ke byte yang diizinkan maksimum?

— bernd_k

@bernd_k: 8060 = jumlah data terbesar untuk satu baris yang sesuai dengan satu halaman 8192. Sertakan overhead baris. Sisa (132 byte) = overhead halaman

— gbn

Itu berarti kinerja berkurang ketika ukuran yang lebih besar benar-benar digunakan, bukan oleh fakta murni, bahwa penggunaannya diperbolehkan.

— bernd_k

@bernd_k: penurunan kinerja apa pun disebabkan oleh 1. alokasi memori untuk jenis dll. 2. Overflow baris (> 8060 byte). Fakta memiliki 10 karakter di setiap varchar (8000) tidak relevan sampai kondisi ini terpenuhi (SQL akan memperingatkan tentang kesalahan potensial nanti untuk kunci indeks)

— gbn

Apakah mengurutkan tabel dengan kolom varchar (100) diisi dengan bidang dengan panjang 100 byte, patut dipertanyakan, karena pengurutan mengasumsikan rata-rata 50 karakter?

— bernd_k

7

Dengan asumsi Anda merujuk ke SQL Server, saya bisa memikirkan satu.

Ada batas ukuran (8K) dari sebuah baris dalam sebuah tabel dan SQL memungkinkan Anda mendefinisikan bidang varchar yang secara teoritis dapat melebihi batas itu. Jadi pengguna bisa mendapatkan kesalahan jika mereka memasukkan terlalu banyak data di bidang yang terkait dengan itu.

Dimulai dengan SQL 2K8 Anda dapat melebihi batas ini, tetapi ada implikasi kinerja .

Juga, ada seluruh kewajaran memeriksa membatasi ukuran untuk apa yang Anda harapkan dari data. Jika Anda ingin bidang panjang yang tidak terbatas mengapa tidak pergi dengan teks atau ntext?

— JohnFx
sumber

jadi tipe data teks dan nteks disimpan dengan cara yang tidak memengaruhi kinerja?

— Chad

Jenis-jenis itu tidak berkontribusi sebanyak batas ukuran baris 8K pada tabel karena data aktual disimpan dalam tabel terpisah di bawah penutup alih-alih sejalan dengan sisa kolom. Masih ada dampak kinerja, tetapi karena berbagai alasan. Ada juga batasan pada dukungan fitur pada bidang-bidang ini bila dibandingkan dengan varchar dan nvarchar

— JohnFx

teks dan ntext tidak digunakan lagi karena mendukung varchar (maks).

— Phil Helmer

3

Tentunya itu tergantung pada informasi apa yang sedang disimpan di lapangan?

Beberapa hal akan memiliki panjang maksimum karena sejumlah alasan dan jika harus ada panjang maksimum maka itu harus menjadi panjang bidang Anda.

Jika secara teoritis tidak ada panjang maksimum maka saya akan mempertanyakan mengapa varchar akan digunakan.

— Toby
sumber

3

Saya konteks Oracle Databases saya belajar bahwa selalu menggunakan ukuran bidang terkecil untuk kolom Database memiliki satu perangkap.

Ketika memindahkan data melalui ekspor impor dari database dengan satu byte byte ke satu dengan beberapa byte byte (seperti Oracle XE) panjang dalam byte dapat meningkatkan dan mengimpor data ke dalam tabel yang dibuat oleh impor gagal. Tentu saja Oracle memiliki opsi untuk menentukan panjang varchar2 baik sebagai char atau sebagai byte.

Maksud saya di sini, adalah tidak selalu bijaksana untuk mendefinisikan bidang dengan selalu sekecil mungkin. Saya telah melihat banyak tabel alter untuk menambah withs nanti (disebabkan oleh perubahan persyaratan).

Memiliki 20% - 100% bidang yang tidak digunakan dengan adalah opsi yang dapat dibicarakan di sini.

— bernd_k
sumber