Evolución de los SGBD

Con el inicio de los ordenadores para la automatización de la gestión empresarial, también surge la
historia y evolución de las bases de datos, más específicamente a mediados de los años cincuenta.

En 1970 se propuso un modelo relacional basado en los trabajos matemáticos del Dr. Codd (que dio
las raíces de la segunda generación de SGBD), quien propuso un modelo en el que los datos serían
representados en tablas constituidas por filas y columnas, a las tablas se les daría el nombre de
relaciones, de ahí el nombre de “Sistema relacional”, su característica principal fue su mayor
independencia física-lógica por el hecho de actuar sobre conjuntos de registros. El enfoque
relacional permite el manejo de tuplas procedentes de distintos ficheros y tablas de una misma base,
mediante consultas estructuradas, habilitando acciones múltiples sobre los registros.

El Dr. Codd también propuso dos lenguajes para manipular los datos: álgebra y cálculo relacional
que manipulan los datos con base de operadores lógicos y no de punteros físicos (utilizados en
modelos jerárquicos y de red). Como resultado se crearon sistemas relacionales durante la última
mitad de los setenta que soportaban leguajes como “SQL”, “QUEL” y “QBE”.

Un gran salto fue en la primera mitad de la década de los ochenta donde el lenguaje SQL se
estandariza, esto permitió una mayor integración, multiplicó tareas asignadas a las bases de datos y
amplio el desarrollo de sistemas de uso transparente, todo ayudando a una excelente productividad
e impacto económico.

La tercera generación de SGBD, tiene como característica principal la optimización relacional de los
sistemas en entornos multiusuario, la gestión de objetos permitiendo datos complejos, el
encapsulamiento de la semántica de datos que proporciona un soporte para recuperación de
información y mantenimiento de las restricciones de integridad entre datos.

En esta generación destacan dos indicadores: Una arquitectura de tres niveles con descripción
recursiva de datos (ANSI, ISO) como referencia y el modelo relacional.

Windows VS Linux

Existen varios puntos clave que ayudan mucho en la toma de decisión de cual usar, estos son
algunos de ellos:

Instalación

Linux: La instalación no es sencilla, pero permite personalizar los paquetes que quieras instalar.

Windows: La instalación es muy sencilla, pero mínimamente configurable.

Compatibilidad

Ninguno de los dos es 100% compatible con el Hardware, aunque no es un gran problema.

Linux: No es de ninguna marca, por lo que ofrece una gran compatibilidad y actualización frecuente.
Windows: Como es de Microsoft, trata de ofrecer una gran cantidad de drivers y gracias a su gran
economía hace que las empresas creen sus propios drivers.

Software

Linux: Como no tiene gran uso y aceptación en las empresas, sufre de tener menos software.

Windows: Como es el más fácil de usar a nivel empresarial, tiene una gran cantidad de Software.

Robustez

Linux: Tiene una gran robustez en su sistema ya que no tiene necesidad de apagar o reiniciar el
equipo en meses o años, además de que, si una aplicación falla, no bloquea todo el equipo.

Windows: Es necesario reiniciar el equipo cuando hay cambios de configuración del sistema,
además de su bloqueo de equipo que obliga a reiniciar el equipo.

Conclusión:

Evidentemente existen ventajas y desventajas en ambos casos y depende del usuario la decisión
final, no obstante, a nivel técnico es claro que el vencedor es Linux.

Open Data Base Conectivity

Si escribimos una aplicación para acceder a las tablas de una DB de Access, pero después
queremos utilizar tablas SQL u otra DB, no funcionara, esto porque no hay una compatibilidad entre
los motores concretos, además de que las DB no funcionan igual,

No obstante, el avance tecnológico ha hecho posible que hoy día existan “piezas intercambiables”
que hacen que pueda existir un dialogo entre otras DB, a estos se les llaman Orígenes de datos de
ODBC.

La idea principal se basa en que de un lado el ODBC provea de unas características siempre
homogéneas y por el otro lado permita distintos controladores que aseguren la conectividad de la
aplicación con diferentes DB.

Tipos de dato en una base de datos MySQL

Cuando se crea una tabla, es importante hacer una elección correcta de formato de dato para cada
columna de la tabla, para una mayor eficiencia y un rendimiento óptimo a medio y largo plazo.

Existen tres tipos de datos: Numéricos, Fecha, String.

Datos numéricos en MySQL (ocupación en disco y valores).

INT (INTEGER): Ocupación de 4 bytes con valores entre -2147483648 y 2147483647 o entre 0 y
4294967295. // SMALLINT: Ocupación de 2 bytes con valores entre -32768 y 32767 o entre 0 y
65535. // TINYINT: Ocupación de 1 bytes con valores entre -128 y 127 o entre 0 y 255. //
MEDIUMINT: Ocupación de 3 bytes con valores entre -8388608 y 8388607 o entre 0 y 16777215. //
BIGINT: Ocupación de 8 bytes con valores entre -8388608 y 8388607 o entre 0 y 16777215. //
DECIMAL (NUMERIC): Almacena los números de coma flotante como cadenas o string. // FLOAT
(m, d): Almacena números de coma flotante, donde ‘m’ es el número de dígitos de la parte entera y
‘d’ el número de decimales. // DOUBLE (REAL): Almacena número de coma flotante con precisión
doble. Igual que FLOAT, la diferencia es el rango de valores posibles. // BIT (BOOL, BOOLEAN):
Número entero con valor 0 o 1.
Datos Fecha en MySQL (ocupación en disco y valores).

DATE: Válido para almacenar una fecha con año, mes y día, su rango oscila entre ‘1000-01-01′ y
‘9999-12-31′. // DATETIME: Almacena una fecha (año-mes-día) y una hora (horas-minutos-
segundos), su rango oscila entre ‘1000-01-01 00:00:00′ y ‘9999-12-31 23:59:59′. // TIME: Válido para
almacenar una hora (horas-minutos-segundos). Su rango de horas oscila entre -838-59-59 y 838-59-
59. El formato almacenado es ‘HH:MM: SS’. // TIMESTAMP: Almacena una fecha y hora UTC. El
rango de valores oscila entre ‘1970-01-01 00:00:01′ y ‘2038-01-19 03:14:07′. // YEAR: Almacena un
año dado con 2 o 4 dígitos de longitud, por defecto son 4. El rango de valores oscila entre 1901 y
2155 con 4 dígitos. Mientras que con 2 dígitos el rango es desde 1970 a 2069 (70-69).

Datos String en MySQL (ocupación en disco y valores).

CHAR: Ocupación fija cuya longitud comprende de 1 a 255 caracteres. // VARCHAR: Ocupación
variable cuya longitud comprende de 1 a 255 caracteres. // TINYBLOB: Una longitud máxima de 255
caracteres. Válido para objetos binarios como son un fichero de texto, imágenes, ficheros de audio o
vídeo. No distingue entre minúsculas y mayúsculas. // BLOB: Una longitud máxima de 65.535
caracteres. Válido para objetos binarios como son un fichero de texto, imágenes, ficheros de audio o
vídeo. No distingue entre minúsculas y mayúsculas. // MEDIUMBLOB: Una longitud máxima de
16.777.215 caracteres. Válido para objetos binarios como son un fichero de texto, imágenes, ficheros
de audio o vídeo. No distingue entre minúsculas y mayúsculas. // LONGBLOB: Una longitud máxima
de 4.294.967.298 caracteres. Válido para objetos binarios como son un fichero de texto, imágenes,
ficheros de audio o vídeo. No distingue entre minúsculas y mayúsculas. // SET: Almacena 0, uno o
varios valores una lista con un máximo de 64 posibles valores. // ENUM: Igual que SET, pero solo
puede almacenar un valor. // TINYTEXT: Una longitud máxima de 255 caracteres. Sirve para
almacenar texto plano sin formato. Distingue entre minúsculas y mayúsculas. // TEXT: Una longitud
máxima de 65.535 caracteres. Sirve para almacenar texto plano sin formato. Distingue entre
minúsculas y mayúsculas. // MEDIUMTEXT: Una longitud máxima de 16.777.215 caracteres. Sirve
para almacenar texto plano sin formato. Distingue entre minúsculas y mayúsculas. // LONGTEXT:
Una longitud máxima de 4.294.967.298 caracteres. Sirve para almacenar texto plano sin formato.
Distingue entre minúsculas y mayúsculas.