Différence entre chaîne et texte dans les rails?

Je crée une nouvelle application Web à l'aide de Rails et je me demandais quelle est la différence entre stringet text? Et quand faut-il les utiliser?

La différence repose sur la façon dont le symbole est converti en son type de colonne respectif dans le langage de requête.

avec MySQL: la chaîne est mappée sur 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)

Référence:

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

Quand faut-il utiliser chacun?

En règle générale, utilisez-le :stringpour la saisie de texte court (nom d'utilisateur, e-mail, mot de passe, titres, etc.) et utilisez-le :textpour une saisie plus longue, comme les descriptions, le contenu des commentaires, etc.

Si vous utilisez postgres, utilisez du texte partout où vous le pouvez, sauf si vous avez une contrainte de taille car il n'y a pas de pénalité de performance pour le texte vs varchar

Il n'y a pas de différence de performances entre ces trois types, à part un espace de stockage accru lors de l'utilisation du type à remplissage vierge et quelques cycles CPU supplémentaires pour vérifier la longueur lors du stockage dans une colonne à longueur limitée. Bien que le caractère (n) présente des avantages en termes de performances dans certains autres systèmes de base de données, il n'y en a pas dans PostgreSQL; en fait, le caractère (n) est généralement le plus lent des trois en raison de ses coûts de stockage supplémentaires. Dans la plupart des situations, le texte ou les caractères variant doivent être utilisés à la place

Manuel de PostsgreSQL

La chaîne se traduit par "Varchar" dans votre base de données, tandis que le texte se traduit par "texte". Un varchar peut contenir beaucoup moins d'éléments, un texte peut avoir (presque) n'importe quelle longueur.

Pour une analyse approfondie avec de bonnes références, consultez http://www.pythian.com/news/7129/text-vs-varchar/

Modifier: certains moteurs de base de données peuvent se charger varcharen une seule fois, mais stocker du texte (et un blob) en dehors du tableau. Un SELECT name, amount FROM productspourrait être beaucoup plus lent lors de l'utilisation textde nameque lors de l'utilisation varchar. Et depuis Rails, par défaut, les enregistrements chargés avec SELECT * FROM...vos colonnes de texte seront chargés. Ce ne sera probablement jamais un vrai problème dans votre application ou dans celle-ci (l'optimisation prématurée est ...). Mais savoir que le texte n'est pas toujours "gratuit" est bon à savoir.

Chaîne si la taille est fixe et petite et texte si elle est variable et grande. C'est assez important parce que le texte est bien plus gros que les chaînes. Il contient beaucoup plus de kilo-octets.

Donc, pour les petits champs, utilisez toujours string (varchar). Des domaines comme. prénom, login, email, sujet (d'un article ou d'un post) et exemple de textes: contenu / corps d'un post ou d'un article. champs pour les paragraphes, etc.

Taille de chaîne 1 à 255 (par défaut = 255)

Taille du texte 1 à 4294967296 (par défaut = 65536) 2

Comme expliqué ci-dessus, non seulement le type de données db, il affectera également la vue qui sera générée si vous êtes un échafaudage. chaîne générera un text_field texte générera un text_area

Utilisez une chaîne pour un champ plus court, comme les noms, l'adresse, le téléphone, la société

Utilisez du texte pour un contenu plus large, des commentaires, du contenu, des paragraphes.

Ma règle générale, si c'est quelque chose qui est plus d'une ligne, je vais généralement pour le texte, si c'est un court 2-6 mots, je vais pour la chaîne.

La règle officielle est 255 pour une chaîne. Donc, si votre chaîne contient plus de 255 caractères, optez pour le texte.

Si vous utilisez oracle ... STRINGsera créé comme VARCHAR(255)colonne et TEXT, comme 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

La réponse acceptée est impressionnante, elle explique correctement la différence entre la chaîne et le texte (principalement la taille limite dans la base de données, mais il y a quelques autres pièges), mais je voulais souligner un petit problème qui m'a permis de passer au travers de cette réponse ne l'a pas complètement fait pour moi.

La taille maximale : limit => 1 à 4294967296 ne fonctionnait pas exactement comme indiqué, je devais aller à -1 à partir de cette taille maximale. Je stocke de gros blobs JSON et ils peuvent parfois être énormes.

Voici ma migration avec la plus grande valeur en place avec la valeur dont MySQL ne se plaint pas.

Notez le 5 à la fin de la limite au lieu de 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

Si l'attribut est correspondant à f.text_fieldl'utilisation de la forme chaîne , si elle est correspondant à l' f.text_areautilisation du texte .