Diferența dintre șir și textul în sine?

Diferența constă în modul în care simbolul este transformată în coloana respectivă tip în limbaj de interogare.

cu MySQL :string este mapat la 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)

Referință:

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

Atunci când fiecare ar trebui să fie utilizate?

Ca o regulă generală de degetul mare, folosesc:stringpentru scurt text de intrare (nume de utilizator, e-mail, parola, titluri, etc.) și de a folosi:text` pentru mai mult timp așteptat de intrare, cum ar fi descrieri, observații de conținut, etc.

Dacă utilizați postgres utilizarea de text ori de câte ori poți, dacă nu au o dimensiune de constrângere, deoarece nu există nici o penalizare de performanță pentru text vs varchar

nu Există nici o diferență de performanță între aceste trei tipuri, în afară de spațiu de stocare mai mare atunci când se utilizează gol căptușit tip, și un plus cateva cicluri CPU pentru a verifica lungimea atunci când stocarea într-o lungime limitată în coloană. În timp ce personajul(n) are avantaje de performanță în alte sisteme de baze de date, nu există nici un astfel de avantaj în PostgreSQL; în fapt, personajul(n) este de obicei cel mai lent dintre cele trei, din cauza sale costuri de depozitare suplimentare. În cele mai multe situații text sau caractere diferite ar trebui să fie folosit în loc

PostsgreSQL manual

Șir se traduce prin "Varchar" în baza dumneavoastră de date, în timp ce textul se traduce prin "text". Un varchar poate conține mult mai puține elemente, un text poate fi de (aproape) orice lungime.

Pentru o analiză în profunzime cu referințe bune verifica http://www.pythian.com/news/7129/text-vs-varchar/

Editare: Unele motoare de baze de date poate încărca varchar într-un du-te, dar, magazin de text (și blob) în afara mesei. O SELECT nume, cantitate DE produse ar putea fi mult mai lent atunci când se utilizează "text" pentru "nume" decât atunci când utilizațivarchar. Și de Șine, în mod implicit mulțime de înregistrări cuSELECT * FROM...` text-coloanele vor fi încărcate. Acest lucru va fi, probabil, niciodată o problemă reală în sau aplicația mea, deși (Premature optimization este ...). Dar știind că textul nu este întotdeauna "gratuit" este bine să știi.

Șir dacă dimensiunea este fix și mici și text dacă este variabilă și mai mare. Acest lucru este destul de important, deoarece textul este mult mai mare decât siruri de caractere. Acesta conține o mulțime mai mult de kilobytes.

Deci, pentru domenii mici, utilizați întotdeauna string(varchar). Domenii cum ar fi. first_name, autentificare, e-mail, subiect (de un articol sau post) și exemplu de texte: conținut/corpul unui mesaj sau articol. domeniile pentru punctele etc

Șir de dimensiune 1 la 255 (default = 255)

Dimensiunea textului de la 1 la 4294967296 (default = 65536)2

Așa cum sa explicat mai sus, nu doar db tip de date nu va afecta, de asemenea, de părere că vor fi generate în cazul în care sunteți schele. string va genera un text_field text va genera un text_area

Utilizarea șir pentru mai scurte domeniu, cum ar fi numele, adresa, telefon, compania

Utilizarea de Text mai mari de conținut, comentarii, conținut, paragrafe.

Mi regulă generală, dacă-l's ceva care este mai mult de o linie, eu de obicei merg pentru text, dacă-l's o scurtă 2-6 cuvinte, mă duc pentru string.

De regulă oficială este de 255 pentru un șir de caractere. Deci, dacă șirul este mai mult de 255 de caractere, du-te pentru text.

Acceptat răspunsul este minunat, corect explică diferența dintre șir vs text (cu cea mai mare limita de dimensiune în baza de date, dar există câteva alte chestii), dar am vrut să subliniez o mica problema care m-a ajutat ca acest raspuns nu't complet fă-o pentru mine.

Dimensiunea maxima :limita => 1 4294967296 am't lucra exact ca a pus, trebuia să merg -1 din acea dimensiune max. Am'm depozitarea mare JSON blobs și acestea ar putea fi nebunie mare uneori.

Aici's migrației mea cu valoarea cea mai mare în loc cu valoarea MySQL nu't se plâng.

Notă 5 la sfârșitul limită în loc de 6

`` clasa ChangeUserSyncRecordDetailsToText < ActiveRecord::Migrația[5.1] def sus change_column :user_sync_records, :detalii :text :limita => 4294967295 end

def jos change_column :user_sync_records, :detalii :string, :limita => 1000 end end ``

Dacă utilizați oracle... "STRING" va fi creat ca VARCHAR(255) coloană și TEXT, ca un 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

Dacă atributul este de potrivire f.text_field în formă de utilizare **string**, dacă este potriviref.text_area utilizarea text.