VARCHAR sütunlarına isteğe bağlı bir uzunluk sınırı eklemeli miyim?

PostgreSQL'in dokümanlarına göre VARCHAR, VARCHAR(n)ve arasında hiçbir performans farkı yoktur TEXT.

Bir isim veya adres sütununa isteğe bağlı uzunluk sınırı eklemeli miyim ?

Düzenleme: Bir dupe değil:

• Tüm değerler 36 karakter olduğunda, dizin araması char vs varchar ile belirgin şekilde daha hızlı olur mu

CHARTipin geçmişin bir kalıntısı olduğunu biliyorum ve sadece performansla değil, Erwin'in şaşırtıcı cevabında belirtildiği gibi diğer artı ve eksilerle de ilgileniyorum.

Cevap hayır . Bundan kaçınabilmeniz için
bir uzunluk değiştirici eklemeyin varchar. Çoğu zaman, zaten bir uzunluk kısıtlamasına ihtiyacınız yok. Sadece texttüm karakter verileri için kullanın . Sahip varcharolmayan RDBMS ile uyumlu kalmanız gerekiyorsa bunu yapın (uzunluk değiştirici yok) text.

Performans neredeyse aynıdır - textolduğu biraz daha hızlı nadir durumlarda ve uzunluğuna kontrol için döngüleri tasarrufu.

Gerçekten de bir maksimum uzunluk uygulamanız gerekiyorsa , bunun için hala textbir kontrol kısıtlaması kullanın ve ekleyin :

ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);

Tablo tanımını ve tüm bağlı nesneleri (görünümler, işlevler, yabancı anahtarlar, ...) ile uğraşmak zorunda kalmadan istediğiniz zaman böyle bir kısıtlamayı değiştirebilir veya bırakabilirsiniz.

Uzunluk değiştiricileri ile sadece girmek bu gibi sorunlar ya bu ya bu ...

PostgreSQL 9.1, ağrıyı hafifletmek için yeni bir özellik sundu. Burada sürüm notlarını alıntı yapıyorum :

ALTER TABLE ... SET DATA TYPEUygun durumlarda tablo yeniden yazılmamasına izin verin (Noah Misch, Robert Haas)

Örneğin, bir varcharsütunu metne dönüştürmek artık tablonun yeniden yazılmasını gerektirmez. Bununla birlikte, bir varcharsütunda uzunluk sınırını artırmak, yine de bir tablo yeniden yazılmasını gerektirir.

Verileri doğruladığınızdan emin olmak için uzunluk sınırını bir tür kontrol kısıtlaması olarak görüyorsanız, evet bir tane ekleyin. Aslında isteyebilirsiniz değil yapmak yerine bir uzunluk tanımını ama gerçek denetim kısıtlaması kullanmak değişen hızlı sınırı.

Bir uzunluk sınırını değiştirmek (artırmak) için ALTER TABLE, özel bir masa kilidinin gerekli olduğu (masanın yeniden yazılması nedeniyle) bitmesi uzun zaman alabileceğiniz bir koşuya ihtiyacınız var .

Bir kontrol kısıtlamasını değiştirme (yani bırakma ve yeniden oluşturma) çok kısa bir işlemdir ve yalnızca tablonun verilerini okumayı gerektirir, herhangi bir satırı değiştirmez. Bu çok daha hızlı olacak (sırayla özel masa kilidi çok daha kısa bir süre tutulacak demektir).

Çalışma sırasında a text, a varcharveya varchar(5000)sütun arasında hiçbir fark yoktur .

Soru özellikle olup olmadığıdır bir ekleme keyfi uzunluk VARCHAR sütunları sınırı?

Bunun için cevap basitçe "hayır" dır. Sizin varchar(max)gibi sözleşmeleri destekleyen veya kullanan alt veritabanlarında olduğu gibi isteğe bağlı bir sınır eklemeyi haklı çıkaracak hiçbir şey yoktur varchar(255). Ancak, eğer özellik bir limiti ele alırsa, özellikle PostgreSQL'in modern versiyonlarında cevabın çok daha karmaşık hale geldiğini düşünüyorum. Ve bunun için YES'e yaslanacağım .

Benim görüşüme göre, şartname gerektiriyorsa, sınır akıllıca bir seçimdir. Özellikle daha makul iş yükleri için. Başka bir nedenden ötürü meta verileri korumak için.

Buradaki cevabımdan , meta-verilerin değerini belirttiğim CHAR-VARCHAR (Postgres) için endeks performansı .

Değişken uzunlukta metin tuşları olan ve anlamlı bir uzunluk uzunluğuna sahip olduğum için güvendiğim bir özellik bulursam, ben de kullanırdım varchar. Ancak, bu kriterlere uyan bir şey düşünemiyorum.

Çok VARCHARuzun dizeleri saklamak için düzenli olarak kullanılırsa, "uzun dizeler sistem tarafından otomatik olarak sıkıştırılır" ve "çok uzun değerler de arka plan tablolarında depolanır" diye bir performans farkı olabilir gibi görünüyor . Teorik olarak, bu çok uzun bir dize alanı için yüksek miktarda istek, kısa bir dize alanı için daha yavaş olacağı anlamına gelir. İsimler ve adresler çok uzun sürmeyeceğinden muhtemelen bu problemle asla karşılaşmazsınız.

Ancak, bu dizeleri veritabanınız dışında nasıl kullandığınıza bağlı olarak, sistemin kötüye kullanılmasını önlemek için pratik bir sınır eklemek isteyebilirsiniz. Örneğin, bir yerde bir formdaki adı ve adresi görüntülüyorsanız, "ad" alanında bir metin paragrafı gösteremeyebilirsiniz, bu nedenle ad sütununu 500 gibi bir değerle sınırlamak mantıklı olacaktır. karakter.