Perbedaan antara string dan teks di rel?


436

Saya membuat aplikasi web baru menggunakan Rails, dan bertanya-tanya, apa bedanya antara stringdan text? Dan kapan masing-masing harus digunakan?

Jawaban:


523

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:

http://www.packtpub.com/article/Working-with-Rails-ActiveRecord-Migrations-Models-Scaffolding-and-Database-Completion

Kapan masing-masing harus digunakan?

Sebagai pedoman umum, gunakan :stringinput teks pendek (nama pengguna, email, kata sandi, judul, dll.) Dan gunakan :textinput input yang lebih panjang seperti deskripsi, konten komentar, dll.


11
Saya pikir aturan praktis yang lebih baik adalah selalu menggunakan :text. Lihat depesz.com/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text
Reed G. Law

74
Untuk MySQL - tidak terlalu banyak, Anda dapat memiliki indeks pada varchars, Anda tidak dapat pada teks.
Omar Qureshi

12
Implementasi PostgreSQL lebih suka teks. Satu-satunya perbedaan untuk string / teks pg adalah batasan panjang untuk string. Tidak ada perbedaan kinerja.
Andy Bettisworth

Tampaknya ini bukan keseluruhan cerita dengan ActiveRecord. Menyimpan nilai trueke varchar (ergo, stringketik bidang) di MySQL membuat serial nilai untuk 1(yang benar-benar adil). Namun, di bawah texttipe, 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?
Peter

1
@ elli0t itu berarti Anda tidak akan dapat mengindeks. Jika ini penting, maka Anda sebaiknya tidak menggunakan teks pada MySQL
Omar Qureshi

157

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

Manual PostsgreSQL


4
Tetapi untuk kepentingan menjadi agnostik basis data, apakah ini pendekatan terbaik? Bagaimana jika Anda ingin mengubah database? Saya akui, di dunia nyata itu tidak sering terjadi, tapi tetap saja ... jika tidak ada perbedaan kinerja mengapa tidak menempel pada penggunaan string yang diharapkan untuk hal-hal pendek dan teks untuk hal-hal yang lebih lama? Dan mengingat string pengindeksan komentar Anda sendiri, tampaknya masih pendekatan terbaik.
Dan Barron

6
Ada sejumlah alasan mengapa hal itu mungkin diperlukan di Dunia Nyata, di mana yang terbaik adalah menumpahkan anggapan bahwa ada Satu Solusi Sejati untuk setiap masalah.
Dan Barron

14
Mungkin memang begitu, tetapi basis data agnostisisme adalah nabi palsu.
Omar Qureshi

2
Adakah yang punya informasi tentang apakah penalti kinerja itu signifikan atau apakah ini kasus optimisasi dini? Dugaan saya adalah Anda tidak akan pernah melihat perbedaan, yang pembukaan paragraf tampaknya mengkonfirmasi: "Tidak ada perbedaan kinerja di antara ketiga jenis ini".
Dennis

5
Anda membuat poin yang bagus, tapi saya tidak sepenuhnya yakin. Argumen dalam posting blog untuk menggunakan textlebih dari (n)tipe data meyakinkan, tetapi argumen untuk menggunakan textlebih dari varchartidak. Dia mengatakan mereka sama tetapi lebih suka textkarena varchardapat dikacaukan dengan varchar(n)dan karena textlebih sedikit karakter untuk diketik. Tetapi textalih-alih menggunakan varchar, Anda kehilangan konteks bahwa data yang disimpan tidak boleh lama. Sebagai contoh, menyimpan nama pengguna dengan texttampaknya menyesatkan bagi saya.
Dennis

17

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 varchardalam sekali jalan, tetapi menyimpan teks (dan gumpalan) di luar tabel. Sebuah SELECT name, amount FROM productsbisa, menjadi jauh lebih lambat bila menggunakan textuntuk namedaripada 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.


12

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


11

Seperti dijelaskan di atas bukan hanya datatype db, itu juga akan mempengaruhi tampilan yang akan dihasilkan jika Anda perancah. string akan menghasilkan text_field teks akan menghasilkan text_area


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.


1

Jika Anda menggunakan oracle ... STRINGakan 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 }
}

https://github.com/rsim/oracle-enhanced/blob/master/lib/active_record/connection_adapters/oracle_enhanced_adapter.rb


1

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

0

Jika atribut yang cocok f.text_fielddi string menggunakan formulir , jika cocok dengan f.text_areamenggunakan teks .

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.