2010-05-19 6 views
6

¿Por qué cada RDBMS insiste en que le diga cuál es la longitud máxima de un campo de texto? ¿Por qué no puede inferir esta información de los datos que se ingresan en la base de datos?¿Por qué tengo que establecer la longitud máxima de cada columna de texto en la base de datos?

He trabajado principalmente con MS SQL Server, pero cualquier otra base de datos que conozco también exige que establezca estos límites arbitrarios en su esquema de datos. La realidad es que esto no es particularmente útil o amigable para trabajar, ya que los requisitos del negocio cambian todo el tiempo y casi todos los días algunos usuarios finales intentan poner mucho texto en esa columna.

¿Alguien con un poco de conocimiento interno de un RDBMS sabe por qué no deducimos los límites de los datos que se guardan en el almacenamiento? No estoy hablando de adivinar la información del tipo, sino de adivinar los límites de una columna de texto en particular.

Es decir, hay una razón por la que no uso nvarchar (max) en cada columna de texto en la base de datos.

+0

tengo ningún "conocimiento práctico interior de un RDBMS" , pero no entiendo por qué piensas que esto es un problema. Hay tipos de datos independientes como CLOB. Si eso es lo que quieres, entonces úsalo. Si necesita hacer comparaciones de texto más fáciles, entonces tiene que sufrir el dolor de escribir (255) o lo que sea. No parece que valga la pena quejarse por mí. Pero eso es solo mi granito de arena. – MJB

+2

Vale la pena señalar que SQLite no impone este requisito. – cikkle

+0

Es lógicamente imposible inferir una longitud máxima de los datos realmente dados. ¿Cuánto tiempo debe esperar la base de datos hasta que decida, "OK, supongo que nunca habrá más de 255 caracteres aquí"? –

Respuesta

5

Porque las computadoras (y las bases de datos) son estúpidas.Las computadoras no adivinan muy bien y, a menos que se las explique, no pueden decir que se va a usar una columna para un número de teléfono o una copia de War and Peace. Obviamente, la base de datos podría diseñarse para que cada columna pueda contener una cantidad infinita de datos, o al menos tanto como lo permita el espacio en disco, pero sería un diseño muy ineficiente. A fin de obtener eficiencia, hacemos un intercambio y hacemos que el diseñador diga a la base de datos cuánto esperamos poner en la columna. Presumiblemente, podría haber un valor predeterminado, de modo que si no especifica uno, simplemente lo usa. Desafortunadamente, cualquier incumplimiento sería probablemente inapropiado para la gran mayoría de las personas desde una perspectiva de eficiencia.

+0

Una columna que contiene un número de teléfono generalmente se establecerá, digamos alrededor de 10 caracteres. Cuando este es el caso, tiene mucho sentido que la base de datos trate eso como, por ejemplo, varchar (13). Para las columnas que varían mucho donde no hay consenso, el peor de los casos sería que la columna prefija varchar (max) y para estos escenarios sería útil tener un tipo de datos de texto autoajustable. –

+0

@John - entonces, lo que realmente está preguntando no es que las bases de datos actuales simplemente infieran un valor predeterminado, sino que los motores de almacenamiento de bases de datos cambian fundamentalmente la forma en que asignan el almacenamiento. Honestamente, no he investigado mucho sobre ese tema, pero me imagino que eventualmente esquemas como ese terminan sacando datos de caracteres en su propio "contenedor", muy similar y con los mismos problemas de varchar (max). Es un experimento de pensamiento interesante, pero no particularmente relevante para mi trabajo diario. – tvanfosson

+0

Supongo que sí. Sin embargo, creo que el tipo de datos varchar (max) es mucho mejor para estos escenarios de lo que pensaba originalmente. Parece que realmente hace algunas decisiones de almacenamiento dentro/fuera de la fila dependiendo del tamaño del valor. –

0

Creo que es porque los RDBMS usan acceso aleatorio a los datos. Para hacer un acceso aleatorio a los datos, deben saber en qué dirección del disco duro deben saltar para leer rápidamente los datos. Si cada fila de una sola columna tiene una longitud de datos diferente, no pueden inferir cuál es el punto de inicio de la dirección que tienen que saltar directamente para obtenerla. La única forma es que tengan que cargar todos los datos y verificarlos.

Si RDBMS cambian la longitud de datos de una columna a un número fijo (por ejemplo, longitud máxima de todas las filas) cada vez que agregue, actualice y elimine. Es extremadamente lento.

+0

excepto logran optimizar realmente que con un varchar - un carchar (3000) no asigna todos los 3000 bytes todo el tiempo de todos modos;) – TomTom

+0

@Tomtom - suena como que no hay argumento para no establecer cada uno al (8000) desde la memoria no es un problema – JeffO

1

This post no solo responde a su pregunta acerca de si usar nvarchar(max) en todas partes, sino que también proporciona una idea de por qué las bases de datos históricamente no lo permitieron.

1

Esto es como decir, ¿por qué no podemos simplemente decirle a la base de datos que queremos una tabla y dejar que infiera qué tipo y cuántas columnas necesitamos de los datos que le damos?

Simplemente, sabemos mejor que la base de datos. Supone que tiene una probabilidad de uno en un millón de poner una cadena de 2.000 caracteres en la base de datos, la mayoría de las veces, son 100 caracteres. La base de datos probablemente explotaría o rechazaría la cadena de 2k caracteres. Simplemente no puede saber que necesitará 2k de longitud si durante los primeros tres años solo ingresó 100 cadenas de longitud.

Además, la longitud de los caracteres se usa para optimizar la ubicación de filas para que las filas se puedan leer/saltar más rápido.

0

¿En qué basaría la base de datos? Si los requisitos del negocio cambian regularmente, será tan sorprendente como usted. Si hay una razón por la que no se utiliza nvarchar (max), es probable que haya una razón que no sea por defecto, así que ...

2

Tiene que ver con la velocidad. Si se especifica el tamaño máximo de una cadena, puede optimizar la manera en que se almacena la información para una E/S más rápida. Cuando la velocidad es la clave, lo último que desea es un cambio repentino de todos sus datos solo porque ha cambiado la abreviatura de un estado al nombre completo.

Con el tamaño máximo configurado, la base de datos puede asignar el espacio máximo a cada entidad en esa columna e independientemente de los cambios en el valor, no es necesario cambiar el espacio de direcciones.

+1

pero no hace eso - malas noticias. Cualquier base de datos decente NO usa 3000 bytes para almacenar un campo varchar (3000) con solo 4 caracteres;) Hace mucho tiempo -si. Desde hace 20 años - no. – TomTom

+1

@TomTom: Sin embargo, es útil para la base de datos saber que el campo varchar (3000) no tomará más de 3K caracteres. Es realmente difícil establecer un buen mapeo de filas en sectores de disco sin saber qué tan grande puede llegar una fila. –

+0

¿Cómo puedo decir que mycolumn varchar (max) es diferente de la base de datos que consulta la tabla para MAX (LEN (mycolumn))? En algún momento siempre podrá decir que mycolumn de una fila tiene un tamaño particular, sin embargo ese tamaño no será constante. –

0

Por el bien de un ejemplo, voy a entrar en algunas arenas movedizas y sugerir se compara con las aplicaciones de asignación de memoria (RAM). ¿Por qué los programadores no piden/asignan toda la memoria que necesitan cuando se inicia el programa? Porque a menudo no saben cuánto necesitarán. Esto puede llevar a que las aplicaciones agarren más y más memoria mientras se ejecutan, y quizás también liberando memoria. Y tiene varias aplicaciones ejecutándose al mismo tiempo, nuevas aplicaciones comenzando y el cierre de aplicaciones antiguas. Y las aplicaciones siempre quieren bloques contiguos de memoria, funcionan mal (si es que lo hacen) si su memoria está dispersa por todo el espacio de direcciones. Con el tiempo, esto lleva a una memoria fragmentada y a todos esos problemas de recolección de basura que la gente ha estado rasgando sus cabellos durante décadas.

saltar de nuevo a las bases de datos. ¿Quieres que eso suceda con tus discos duros? (Recuerde, el rendimiento del disco duro es muy, muy lento en comparación con las operaciones de memoria ...)

+0

no veo cómo esto es relevante. Nunca dejaría que el usuario gobierne las asignaciones de memoria arbitrarias. Eso solo es irresponsable y potencialmente un riesgo de seguridad. La base de datos puede compensar su mente en función de las estadísticas; si no se puede llegar a un consenso, se establece de forma predeterminada varchar (max), pero es poco probable que suceda cada vez. –

0

Suena como su regla de negocio es: Escriba la información que desee en cualquier cuadro de texto para que no obtenga enojado con el DBA.

no permiten a los usuarios introducir direcciones de caracteres 5000, ya que no cabrán en el sobre. Es por eso que Twitter tiene un límite de texto y ahorra a todos la molestia de leer a través de un montón de tonterías sin sentido que nunca hace más que enojar al lector haciendo que se pregunten por qué tiene tales disreguard por su tiempo por la elección de un estilo de vida centrado en sí mismo e inhumano centrado en promover el acto de copiar y pegar todos los datos que la memoria tampón dioses permitirán ...

Cuestiones relacionadas