Jawaban:
Perbedaannya bergantung pada bagaimana simbol dikonversi ke masing-masing jenis kolom dalam bahasa query.
dengan MySQL: string dipetakan ke VARCHAR (255) - http://guides.rubyonrails.org/migrations.html
:string | VARCHAR | :limit => 1 to 255 (default = 255)
:text | TINYTEXT, TEXT, MEDIUMTEXT, or LONGTEXT2 | :limit => 1 to 4294967296 (default = 65536)
Referensi:
Kapan masing-masing harus digunakan?
Sebagai pedoman umum, gunakan :string
input teks pendek (nama pengguna, email, kata sandi, judul, dll.) Dan gunakan :text
input input yang lebih panjang seperti deskripsi, konten komentar, dll.
true
ke varchar (ergo, string
ketik bidang) di MySQL membuat serial nilai untuk 1
(yang benar-benar adil). Namun, di bawah text
tipe, menyimpan nilai "true" akhirnya membuat cerita bersambung sebagai karakter tunggal t
. Saya memigrasikan kolom tanpa menyadari ini dan semua baris di masa depan di mana nilainya benar sekarang t
. Adakah yang memiliki wawasan tentang perilaku ini?
Jika Anda menggunakan postgres, gunakan teks di mana pun Anda bisa, kecuali jika Anda memiliki batasan ukuran karena tidak ada penalti kinerja untuk teks vs varchar
Tidak ada perbedaan kinerja di antara ketiga jenis ini, selain dari peningkatan ruang penyimpanan saat menggunakan jenis yang empuk, dan beberapa siklus CPU tambahan untuk memeriksa panjang saat menyimpan ke dalam kolom yang dibatasi panjang. Sementara karakter (n) memiliki keunggulan kinerja di beberapa sistem database lain, tidak ada keunggulan seperti itu di PostgreSQL; sebenarnya karakter (n) biasanya paling lambat dari ketiganya karena biaya penyimpanan tambahan. Dalam kebanyakan situasi, variasi teks atau karakter harus digunakan sebagai gantinya
text
lebih dari (n)
tipe data meyakinkan, tetapi argumen untuk menggunakan text
lebih dari varchar
tidak. Dia mengatakan mereka sama tetapi lebih suka text
karena varchar
dapat dikacaukan dengan varchar(n)
dan karena text
lebih sedikit karakter untuk diketik. Tetapi text
alih-alih menggunakan varchar
, Anda kehilangan konteks bahwa data yang disimpan tidak boleh lama. Sebagai contoh, menyimpan nama pengguna dengan text
tampaknya menyesatkan bagi saya.
String diterjemahkan menjadi "Varchar" di database Anda, sementara teks diterjemahkan menjadi "teks". Sebuah varchar dapat memuat item yang jauh lebih sedikit, teks dapat memiliki panjang (hampir) berapa pun.
Untuk analisis mendalam dengan referensi yang baik, periksa http://www.pythian.com/news/7129/text-vs-varchar/
Sunting: Beberapa mesin basis data dapat memuat varchar
dalam sekali jalan, tetapi menyimpan teks (dan gumpalan) di luar tabel. Sebuah SELECT name, amount FROM products
bisa, menjadi jauh lebih lambat bila menggunakan text
untuk name
daripada ketika Anda menggunakan varchar
. Dan sejak Rails, secara default memuat rekaman dengan SELECT * FROM...
kolom teks Anda akan dimuat. Ini mungkin tidak akan pernah menjadi masalah nyata di aplikasi Anda atau saya, (Optimalisasi prematur adalah ...). Tetapi mengetahui bahwa teks tidak selalu "bebas" adalah baik untuk diketahui.
String jika ukurannya tetap dan kecil dan teks jika itu variabel dan besar. Ini agak penting karena teks jauh lebih besar daripada string. Ini mengandung lebih banyak kilobyte.
Jadi untuk bidang kecil selalu gunakan string (varchar). Bidang suka. first_name, login, email, subjek (artikel atau posting) dan contoh teks: konten / isi posting atau artikel. bidang untuk paragraf dll
Ukuran string 1 hingga 255 (default = 255)
Ukuran teks 1 hingga 4294967296 (default = 65536) 2
Gunakan string untuk bidang yang lebih pendek, seperti nama, alamat, telepon, perusahaan
Gunakan Teks untuk konten yang lebih besar, komentar, konten, paragraf.
Aturan umum saya, jika itu adalah sesuatu yang lebih dari satu baris, saya biasanya memilih teks, jika hanya 2-6 kata, saya menggunakan string.
Aturan resmi adalah 255 untuk sebuah string. Jadi, jika string Anda lebih dari 255 karakter, pilih teks.
Jika Anda menggunakan oracle ... STRING
akan dibuat sebagai VARCHAR(255)
kolom dan TEXT
, sebagai a CLOB
.
NATIVE_DATABASE_TYPES = {
primary_key: "NUMBER(38) NOT NULL PRIMARY KEY",
string: { name: "VARCHAR2", limit: 255 },
text: { name: "CLOB" },
ntext: { name: "NCLOB" },
integer: { name: "NUMBER", limit: 38 },
float: { name: "BINARY_FLOAT" },
decimal: { name: "DECIMAL" },
datetime: { name: "TIMESTAMP" },
timestamp: { name: "TIMESTAMP" },
timestamptz: { name: "TIMESTAMP WITH TIME ZONE" },
timestampltz: { name: "TIMESTAMP WITH LOCAL TIME ZONE" },
time: { name: "TIMESTAMP" },
date: { name: "DATE" },
binary: { name: "BLOB" },
boolean: { name: "NUMBER", limit: 1 },
raw: { name: "RAW", limit: 2000 },
bigint: { name: "NUMBER", limit: 19 }
}
Jawaban yang diterima luar biasa, itu benar menjelaskan perbedaan antara string vs teks (kebanyakan ukuran batas dalam database, tetapi ada beberapa gotcha lainnya), tapi saya ingin menunjukkan masalah kecil yang membuat saya melewatinya sebagai jawaban itu tidak sepenuhnya melakukannya untuk saya.
Ukuran maks : limit => 1 hingga 4294967296 tidak berfungsi dengan tepat, saya harus -1 dari ukuran maks. Saya menyimpan gumpalan JSON besar dan kadang-kadang mereka mungkin gila besar.
Inilah migrasi saya dengan nilai yang lebih besar dengan nilai yang tidak dikeluhkan oleh MySQL.
Perhatikan angka 5 di akhir batas, bukan 6
class ChangeUserSyncRecordDetailsToText < ActiveRecord::Migration[5.1]
def up
change_column :user_sync_records, :details, :text, :limit => 4294967295
end
def down
change_column :user_sync_records, :details, :string, :limit => 1000
end
end
Jika atribut yang cocok f.text_field
di string menggunakan formulir , jika cocok dengan f.text_area
menggunakan teks .
:text
. Lihat depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text