¿Por qué nos importan los tipos de datos?

Question

Específicamente, en los sistemas de administración de bases de datos relacionales, ¿por qué necesitamos saber el tipo de datos de una columna (más probablemente, el atributo de un objeto) en el momento de la creación?

Para mí, los tipos de datos se sienten como una optimización, porque un punto de datos se puede implementar de muchas maneras. ¿No sería mejor asignar roles semánticos y restricciones a un punto de datos y luego hacer que el motor examine internamente y optimice qué tipo de datos mejor sirve al usuario?

Sospecho que aquí es donde está el trabajo pesado y por qué es más fácil preguntar al usuario en lugar de hacer el trabajo.

¿Qué opinas? ¿A donde vamos? ¿Es esto una expectativa realista? ¿O tengo una suposición equivocada?

Answer 1

Tiene razón: la asignación de un tipo de datos a una columna es un detalle de implementación y no tiene nada que ver con la teoría de conjuntos o el cálculo detrás de un motor de base de datos. Como modelo teórico, una base de datos debe ser "sin tipo" y capaz de almacenar lo que le arrojamos.

Pero tenemos que implementar la base de datos en una computadora real con limitaciones reales. No es práctico, desde el punto de vista del rendimiento, hacer que la computadora intente de forma dinámica descubrir la mejor manera de almacenar los datos.

Por ejemplo, supongamos que tiene una tabla en la que almacena algunos millones de enteros. La computadora podría, correctamente, descubrir que debería almacenar cada dato como un valor integral. Pero si algún día intentáramos almacenar una cadena en esa tabla, ¿debería el motor de la base de datos detener todo hasta que convierta todos los datos a un formato de cadena más general?

Lamentablemente, especificar un tipo de datos es un mal necesario.

Answer 2

base de datos es todo sobre el almacenamiento físico, tipo de datos definir esto!

Answer 3

El tipo expresa una restricción deseada en los valores de la columna.

Answer 4

La respuesta es el espacio de almacenamiento y las filas de tamaño fijo.

Las filas de tamaño fijo son mucho, MUCHO más rápidas de buscar que las filas de longitud variable, porque puede buscar directamente el byte correcto si sabe qué número de registro y campo desea.

Editar: Habiendo dicho eso, si utiliza la indexación adecuada en las tablas de su base de datos, las filas de tamaño fijo no son tan importantes como solían ser.

Answer 5

SQLite no le importa.

Otros 's principios de uso que fueron diseñados en los primeros 80 ' RDBMS s, cuando era vital para el rendimiento.

Oracle, por ejemplo, no distingue entre un NULL y una cadena vacía, y mantiene su NUMBER 's como conjuntos de dígitos centesimales.

Eso apenas tiene sentido hoy en día, pero estas fueron soluciones muy inteligentes cuando se estaba desarrollando Oracle.

En una de las bases de datos que desarrollé, sin embargo, se usaron valores no indexados que se almacenaron como VARCHAR2, convertidos dinámicamente en los tipos de datos apropiados dependiendo de varias condiciones.

Sin embargo, eso fue algo muy especial: se utilizó para cargar pares clave-valor de carga masiva en una llamada a la base de datos utilizando colecciones.

Las declaraciones dinámicas SQL se usaron para analizar datos y ponerlos en tablas apropiadas basadas en el nombre de la clave.

Todos los valores se cargaron en la columna temporal VARCHAR2 como están y luego se convirtieron en NUMBER y DATETIME que se colocarán en sus columnas.

Answer 6

No estoy seguro de la historia de los tipos de datos en las bases de datos, pero para mí tiene sentido conocer el tipo de datos de un campo.

¿Cuándo le gustaría hacer una suma de algunos campos que son totalmente varchar? Si sé que un campo es un número entero, tiene mucho sentido hacer una suma, promedio, máximo, etc.

Answer 7

Los tipos de datos explícitos son enormes para la eficiencia y el almacenamiento. Si están implícitos, tienen que ser 'descifrados' y, por lo tanto, incurrir en costos de velocidad. Los índices también serían difíciles de implementar.

Sospecho, aunque no es positivo, que los tipos explícitos también en promedio incurren en menos espacio de almacenamiento. Para los números, especialmente, no hay comparación entre un int binario y una cadena de caracteres de dígitos.

Answer 8

Debería preocuparse por los tipos de datos cuando se trata de filtrar (cláusula WHERE) u ordenar (ORDER BY). Por ejemplo, "200" es INFERIOR a "3" si esos valores son cadenas, y lo contrario cuando son enteros.

Creo que tarde o temprano tendrás que ordenar o filtrar tus datos ("200"> "3"?) O usar algunas funciones agregadas en los informes (como sum() o (avg()). Hasta entonces son buenos con el tipo de datos de texto :)

Answer 9

Hm ... Su pregunta es un poco confusa.

Si lo entiendo correctamente, se pregunta por qué especificamos los tipos de datos para las columnas de la tabla, y por qué el "motor" determina automáticamente qué se necesita para el usuario.

Los tipos de datos actúan como una restricción: aseguran la integridad de los datos. Una columna int nunca tendrá letras, lo cual es bueno. El tipo de datos no se decide automáticamente, lo especifica al crear la base de datos, casi siempre con SQL.

Answer 10

No todas las bases de datos funcionan de esta manera. Se mencionó SQLite anteriormente, pero un conjunto mucho más antiguo de bases de datos también lo hace, bases de datos con varios valores.

Considere UniVerse (ahora una propiedad de IBM). No realiza ninguna validación de datos, ni requiere que especifique de qué tipo es. Las búsquedas son (relativamente) rápidas, ocupan menos espacio (debido a la manera en que almacenan los datos de forma dinámica).

Puede describir cómo se verán los datos con los metadatos (elementos del diccionario), pero ese es el límite de cómo restringe los datos.

Véase el artículo de Wikipedia sobre UniVerse

Answer 11

Cuando usted está empujando la mitad de mil millones de filas en 5 meses después de ir a vivir, cada byte cuenta (en nuestro sistema)

NO hay anti-patrón tal como "Optimización prematura" en el diseño de bases de datos.

El espacio en disco es barato, por supuesto, pero utiliza los datos en la memoria.

Answer 12

Si sabe que se supone que un elemento de datos es un número entero, y elige deliberadamente NO dejar que el DBMS se encargue de hacer cumplir esto, entonces se convierte en SU ​​responsabilidad garantizar todo tipo de cosas como integridad de datos (asegurando que no se puede ingresar el valor 'A' en la columna, asegurando que no se puede ingresar el valor 1.5 en la columna), como la consistencia del comportamiento del sistema (asegurando que el valor '01' se considere igual al valor '1', que no es el comportamiento que obtienes de tipo String), ...

Los tipos se encargan de todo este tipo de cosas para ti.

Answer 13

Un libro que he estado leyendo sobre teoría de bases de datos me dice que el estándar SQL define un concepto de dominio . Por ejemplo, alto y ancho podrían ser dos dominios diferentes. Aunque ambos podrían almacenarse como numéricos (10,2), una columna de alto y ancho no se podría comparar sin el moldeado. Esto permite una restricción de "tipo" que no está relacionada con la implementación.

Me gusta esta idea en general, sin embargo, dado que nunca la he visto implementada, no sé cómo sería usarla. Veo que reduciría la posibilidad de errores al usar valores cuya implementación resulta ser la misma, cuando su dominio conceptual es bastante diferente. También podría ayudar a evitar que las personas comparen centímetros y pulgadas, por ejemplo.

Answer 14

RDBM generalmente requieren la definición de tipos de columna para que pueda realizar búsquedas rápidamente. Si desea obtener la quinta columna de cada fila en un gran conjunto de datos, tener las columnas definidas es una gran optimización.

En lugar de escanear cada fila de algún tipo de delimitador para recuperar la quinta columna (si los anchos de columna no eran de ancho fijo), los RDBM pueden simplemente tomar el elemento en sizeOf (column1 - 4 (bytes)) + sizeOf (column5 (bytes)). Imagínese cuánto más rápido sería en una tabla de digamos 10,000,000 filas.

Como alternativa, si no desea especificar los tipos de cada columna, tiene dos opciones que conozco. Especifique cada columna como varchar (255) y decida qué desea hacer con ella dentro del programa de llamada. O puede usar un sistema de base de datos diferente que use pares clave-valor como Redis.

Answer 15

Restricción es quizás la cosa más importante que se menciona aquí. Existen tipos de datos para garantizar la exactitud de sus datos, por lo que está seguro de poder manipularlos correctamente. Hay 2 formas en que podemos almacenar una fecha. En un tipo de fecha o como una cadena "4 de enero de 1893". Pero la cadena también podría haber sido "4/1 1893", "1/4 1893" o similar. Los tipos de datos lo restringen y define una forma canónica para una fecha.

Además, un tipo de datos tiene la ventaja de que puede someterse a controles. La cadena "0 de febrero de 1975" se acepta como una cadena, pero no debe ser una fecha. ¿Qué tal "30 de febrero de 1983"? Las bases de datos deficientes, como MySQL, no hacen estas comprobaciones por defecto (aunque puedes configurar MySQL para hacerlo, ¡y deberías hacerlo!).

tipos de datos garantizarán la coherencia de sus datos. Este es uno de los conceptos más importantes, ya que mantener sus datos en su sano juicio le ahorrará a su mente la locura.