1 – D: Restricción CHECK

Como siempre digo, esta restricción nos ayuda a mantener integridad de los datos. En un caso anterior, mencioné que en la tabla paquetes a alguien se le podría haber ocurrido poner una columna de “entregado” y con los únicos valores de “si” o “no”. Hasta ahora teníamos que confiar en que se introdujeran los datos correctamente porque no había nada que nos evitara poner “jo” o “21″ o “$&”. Estas validaciones las podemos hacer con CHECK.

La sintaxis debería de ser así

CREATE TABLE paquetes2 (
descripcion varchar(255),
entregado char(2),
CONSTRAINT paquetes_entregado_ck CHECK (entregado=’si’ or entregado=’no’)
)

o

CREATE TABLE paquetes2 (
descripcion varchar(255),
entregado char(2)  CHECK (entregado=’si’ or entregado=’no’)
)

(continuar leyendo…)

No! no nos hemos vuelto locos, este podcast es una grabación de la conversación mantenida después de grabar el GPodcast 1.5, una vez grabado me parecia tonteria desperdiciar tan buen material, a si que aquí teneis, el epílogo del capitulo 1.5 que da fin a la primera temporada de Gpodcast.

Gpodcast 1.5 Epílogo [ 33:23 ] Play Now | Play in Popup | Download

1 – C: Restricción PRIMARY KEY

Algo que toda tabla de base de datos relacional tiene que tener es una clave primaria (primary key). En muchas ocasiones he visto que se simulan esas claves primarias desde php. Como siempre digo, esto es menos eficiente y todo eso pero sobre todo es mucho menos seguro. Los motivos son los de siempre, desde php (y suponiendo que no falle) no deberían de poder meter nuevas filas pero ya sea por un bug en el script o que se use otra aplicación se podrían insertar filas con identificadores repetidos.

La clave primaria es una o varias columnas que son únicas en toda la tabla y que además no puede ser nulo. Prácticamente es como juntar unique y not null (por eso expliqué antes las otras dos). Es importante decidir una buena clave primaria que garantice una buena relación entre las tablas ya que de esta manera podremos realizar consultas muy complejas sin tener que comernos la cabeza. Con esto me refiero a que no es un buen hábito ponerle id_cosa en todas las tablas. Lo ideal es que “compartan” claves de los elementos relacionados.

Otro elemento a tener en cuenta es que mediante las claves primarias podemos perder o ganar mucha eficiencia a la hora de ejecutar consultas. Es importante evitar dentro de todo lo posible claves de tipo VARCHAR precisamente porque un varchar es de tamaño variable y eso le va hacer currar bastante más al SGDB (sistema gestor de bases de datos). Lo ideal es usar datos numericos enteros (INT en caso de mysql) o alfanuméricos de tamaño estático CHAR.

(continuar leyendo…)

Ya tenemos aquí otro podcast, esta vez con dos invitados, ahora ya solos 5! Menudo follón… y hablamos de:

- Lectura de correos. Nukeador quiere organizar un evento mozilla.

- Hacemos promoción al profesor Sadu (ver foto mas abajo)

- !kernel nuevo! Comentamos las mejoras que trae.

- ¿para que sirve wireshark? seguridad informática.

- Que te perderás en el futuro? pasado presente y futuro de los videojuegos.

PROMOS canallas podcast y el gorro del mundo

Música: Painted Dream de The Green Waltz

Recordad votad en la encuesta del concurso de Gpodcast!!

Enlaces comentados

- Videos de Harry Potter

gpodcadt 1.5 [ 2:19:42 ] Play Now | Play in Popup | Download

1- B: Restricción NOT NULL

Algo que también he notado bastante es la ausencia del uso de los valores nulos y que muchas veces son sustituidos indebidamente por 0 en caso de valores numéricos o por cadenas vacías en caso de cadenas de texto.

Tanto a nivel conceptual como a nivel técnico es mucho más correcto usar el valor nulo para indicar que “no hay nada” en vez de un 0 o cadena vacía. Puede parecer algo semejante pero no es lo mismo.

Para un sistema gestor de bases de datos, tanto un 0 como una cadena vacía es contenido y como contenido que es se le reserva un espacio en disco, en memoria y se le trata igual que a un dato normal. Aquí ya tenemos la primera pérdida de eficiencia.

(continuar leyendo…)