¿Hay alguna razón para usar varchar sobre columnas de texto en una base de datos?

Es varcharsólo un remanente de delante textdio la vuelta, o hay casos de uso donde usted quiera usar una varchar? (O charpara el caso ..)

(Uso Postgres y MySQL (MyISAM) a diario, así que eso es lo que más me interesa, pero las respuestas para otras bases de datos son bienvenidas. ^ _-)

— Izkata
fuente

Al menos para SQL Server , textestá en desuso. También hay consideraciones de uso que están relacionadas con el lugar donde se almacenan los datos y cómo se accede a ellos.

— Oded

En algunos DBMS, es posible que no pueda usar una columna de texto en una cláusula sort o where. No estoy familiarizado con Postgres, pero revise su documentación.

— jqa

Esta pregunta de StackOverflow podría proporcionar más información.

— J0ANMM

Respuestas:

En general

textLas columnas no son estándar y son específicas de la implementación. En muchos casos, dependiendo de la base de datos, pueden tener una combinación de una o más de las siguientes restricciones: no indexables , no buscables y no clasificables .

En Postgres

Todos estos tipos se guardan internamente utilizando la misma estructura de datos en C. .

En MySQL

La textcolumna es una versión especializadaBLOB y tiene restricciones de indexación.

Solo estos dos ejemplos pueden extrapolarse a los otros sistemas SQL RDBMS y deben ser motivo suficiente para comprender cuándo elegir un tipo sobre el otro.

Solo para dejarlo implícitamente claro, nunca debe usarlo TEXTya que es propietario y no estándar. Todo lo SQLque escriba contra él no será portátil y se garantizará que le causará problemas en el futuro. Solo use tipos que sean parte del Estándar ANSI .

Úselo CHARcuando sepa que tiene un número fijo de caracteres para cada entrada.
Úselo VARCHARcuando tenga un número variable de caracteres para cada entrada.
Si necesita más almacenamiento del que VARCHARpuede proporcionar, CLOBcon UTF-8codificación o tipo estándar equivalente.
NUNCA lo use TEXTya que no es estándar.

Acepté non standard and implementation specificy not indexable, not searchable and not sortableno me di cuenta. Estaba bajo la impresión de que text estaba estandarizado.

— Izkata

¿te refieres al textestándar ASCII o al textestándar UNICODE :-) o una de las otras media docena de textestándares de codificación?

si va a excavar a través de los documentos de estándares SQL, no creo que encuentre nada textcomo un tipo de carácter. No he visto nada, algunos proveedores lo llaman long chary similares, es básicamente un BLOB con una codificación adjunta.

@JarrodRoberson para ser honesto, hay muchos recursos de buena reputación que concluyen (en el entorno de Postgres) que "siempre usan TEXT". Si va a migrar a una base de datos diferente, eso no es un factor decisivo, especialmente porque tendrá que considerar que los postgres 'ilimitados VARCHAR(debido a TOAST no hay límite de fila como, por ejemplo, con MySQL) pueden no traducirse en ilimitado VARCHARen otras bases de datos de todos modos.

— Kayaman

... y como Postgres no admite CLOB , el penúltimo punto no se cumple. Nunca podrá admitir reemplazos directos aunque se adhiera al estándar. Además de escribir ANSI SQL no es una opción viable en el mundo real, a menos que esté escribiendo SQL de juguete.

— Kayaman

text, varchary chartodos se usan por diferentes razones. Por supuesto, existen diferencias de implementación (cuánto tamaño ocupan, etc.), pero también hay consideraciones de uso e intención . El tipo que usa también le dice algo sobre el tipo de datos que se almacenarán en él (o todos lo usaríamos textpara todo ). Si algo tiene una longitud fija, usamos char. Si tiene una longitud variable con un límite superior bien definido, úselo varchar. Si es un gran fragmento de texto sobre el que tiene poco control, entonces textprobablemente sea su mejor opción.

— Se cayó el sistema
fuente

Entonces, ¿la única diferencia real es duplicar la comprobación de límites que probablemente debería estar en el código del programa de todos modos?

— Izkata

@Izkata: también hay diferencias de implementación. No se trata de verificar límites, se trata del tipo de datos . Un código postal (de EE. UU.) Es siempre un código de 5 dígitos, por lo que usar algo como 'char' se convierte en parte de la definición de este dato. Si solo se tratara de la verificación encuadernada, todos podríamos usar un solo tipo de datos para todo y hacer nuestra verificación y el lado del código de transmisión .

— Sistema

@SystemDown Por lo que yo sé, char, varchar, y textestán diseñados para almacenar el mismo tipo de datos. Entonces, ambas respuestas aquí son sobre la verificación de límites. Si hay diferencias de eficiencia, ¿cuáles son? ¿Por qué usaría varcharmás text?

— Izkata

float y double también se usan para el mismo tipo de datos, pero tienen diferencias y se usan de manera diferente. En cuanto a las diferencias de implementación, no estoy lo suficientemente familiarizado con Postgres para responder que me temo.

— Sistema

@SystemDown Aunque almacenar códigos postales como char (5) puede morderlo si comienza a internacionalizarse. Los códigos postales del Reino Unido varían en longitud y 5 caracteres casi nunca son suficientes. Sin embargo, no sé si el espacio en un código postal del Reino Unido es relevante para el análisis.

— Vatine

Las bases de datos están muy preocupadas por el rendimiento: velocidad y minimización del almacenamiento. En la mayoría de las otras partes del mundo de la informática, no le molestará cuántos caracteres hay en su cadena de caracteres; podría ser uno, podría ser todo el contenido de una enciclopedia; todo es solo una cuerda. De hecho, muchos idiomas ni siquiera te molestan si se trata de una cadena o un número.

Pero a medida que las computadoras se vuelven más rápidas y ganan más memoria, las personas colocan más datos en sus bases de datos y hacen consultas más sofisticadas. Para una base de datos, la CPU y la memoria son tan limitantes hoy como lo fueron en los días de la memoria principal de 64Kb y los discos duros de 10Mb (en computadoras mainframe ).

Un número fijo de bytes es mucho más fácil de manejar que un número de longitud variable. 10 bytes es mucho más fácil de manejar que 1,000,000. Por lo tanto, su base de datos quiere que le dé una pista para poder darle un gigabyte de resultados de terrabytes de datos en microsegundos. Si no está usando su base de datos con tanta fuerza, no necesitará la velocidad que ofrece y se molestará con las preguntas innecesarias. Pero si necesita el rendimiento, estará encantado de darle algunas pistas.

Como se señaló en las otras respuestas, use charsi siempre usa un cierto número de caracteres, varcharsi la longitud puede variar pero no es demasiado grande ( supongo que la mayoría de los DB lo tratan como charo textdependiendo del tamaño), y textsi Podría ser de cualquier longitud. Si su SQL intenta usar una textcolumna, podría ser mejor resumirlo de alguna manera y ponerlo también en una columna charpequeña varchar, luego haga where's order by' y 's' sobre eso. Por supuesto, eso solo si el rendimiento es importante para usted.

— RalphChapin
fuente