14
Mar 13

Pildoritas de Bases de Datos: Diseño de Bases de Datos II

pildoras bbdd

En el anterior artículo de Pildoritas de Bases de Datos hablamos largo y tendido del Diseño de Bases de Datos, en concreto sobre la realización de un digrama Entidad / Relación y su posterior normalización.

Cuando un modelo de datos está normalizado hasta la tercera forma normal nuestro diseño ya es bastante bueno. Gracias a la normalización no deberías tener datos redundantes, ni columnas iguales con enumeraciones (proyecto 1, proyecto2…proyecto n), etc.

No obstante, hay otras consideraciones que debemos tener en cuenta y que paso a mencionar a continuación. Son algunas recomendaciones que creo os resultarán de ayuda si tenéis algún día que realizar el diseño de una BBDD.

No guardes datos innecesarios ni consultes campos que no requieras

Hay que grabarse a fuego una verdad que a veces obviamos: No hay nada más costoso en tiempo que el acceso a BBDD. Por tanto, siempre tenemos que evitar acceder a ella de forma “gratuita”.

Mucha gente piensa eso de que no hay nada malo en guardar todo lo posible en BBDD. De hecho, cuanto más guarde pues mejor, no vaya a ser que un futuro haya datos que no almacenaba y luego hagan falta.

Hay que tener presente que la BBDD consiste en pedir a un servicio (muchas veces en otra máquina) que lea de disco una información y nos la devuelva, así que cuanto mayor sea el tamaño de estas tablas, mayor tiempo nos llevará acceder a ellas.

Es por ello que aquellos datos que puedan calcularse a partir de otros no deben de estar almacenados en la bases de datos. Así mismo, si tenemos que recoger datos de BBDD, deberemos de recuperar los campos que sean necesarios, no hacer, por ejemplo, un SELECT * FROM tabla.

Selecciona el tipo de dato y longitud adecuados

Parece una tontería pero veo a mucha gente poco cuidadosa en este aspecto. Por ejemplo, a la hora de crear un campo de texto, mucha gente decide crear un campo VARCHAR por pura costumbre, cuando a lo mejor en un caso concreto los valores de un campo siempre van a tener una longitud fija y merece la pena mejor crearlo de tipo CHAR, ya que ocupa menos. Otro ejemplo es crear un campo de tipo DATETIME cuando lo que se necesita almacenar es sólo la fecha y valdría un campo DATE. En general, hay que pararse un segundo a ver de qué tipo de dato es cada atributo y con qué longitud debemos crear cada campo.

También hay que tener en cuenta la integridad de datos. En el ejemplo del anterior artículo el Nombre y Apellidos del empleado no deberían aceptar caracteres nulos, o el DNI, en caso de que no fuera una PK, debería de ser único. Podemos pensar que esa validación no tiene sentido si no vamos a recibir ese campo vacío nunca por imposición de la lógica de negocio, pero hay amigos, los caminos del desarrollo software son inescrutables, así que mejor poner control desde BBDD no vaya a ser que nos llevemos una sorpresita y a algún proceso le de por saltarse esta norma y meter a un pobre empleado sin nombre ni apellidos.

Crea índices cuando sea posible

Los índices funcionan un poco como el índice de los libros (así a groso modo y por no liar mucho) y sirven para agilizar el tiempo de ejecución de las consultas de SQL. Usando la analogía del libro, si queremos ir al Capítulo 5, en vez de ir página a página hasta que lleguemos a él, mejor mirar el índice e ir a la página directamente.

La primera pregunta que nos asalta a todos cuando oímos por primera vez hablar sobre ellos es “¿Por qué no ponemos índices en todas las columnas?

A parte de que guardar las relaciones de los índices y los datos de la columna ocupa espacio (a veces más que la propia tabla), tenemos que tener en cuenta que cada vez que insertemos, borremos o actualicemos en la BBDD, tendremos también que consumir tiempo en actualizar la relación del índice.

Por tanto, tener demasiados índices en el fondo acaba empeorando el tiempo de respuesta global del acceso a la base de datos, por lo que crearemos un índice cuando tengamos claro que es beneficioso.

¿Cómo sabemos que es beneficioso? Pues es difícil saberlo. Lo mejor con los índices siempre es realizar un explain plan antes y después de añadir el índice para ver si mejora la respuesta, pero intentaremos marcar unas pautas generales que nos ayudarán a la hora de crear índices eficientes.

Para empezar los índices deben encontrarse más como filtro de nuestras consultas (es decir, en el WHERE) que ser parte de los datos que obtenemos (los campos indicados tras el SELECT).

Tampoco es buena idea marcar como índice aquella columna que tiene muchos valores idénticos. Por ejemplo, una columna booleana que indica True o False no tendría sentido colocarla como índice. Por tanto, un índice debe ser un campo donde muchos de los valores sean distintos. Si la tabla tiene pocos registros tampoco merece la pena crear un índice, ya que no mejorará sustancialmente la el tiempo de respuesta.

Por último, hay que tener también en cuenta cuando se crea un índice la regla de la izquierda. Si filtramos por dos campos en el WHERE muy a menudo, más que indicar dos índices por cada campo deberíamos crear un índice multicolumna. A la hora de utilizar dicho índice multicolumna tenemos que tener en cuenta la regla de la izquierda que os comentaba: Hay que incluir en el WHERE las columnas indexadas por orden de izquierda a derecha al igual están definidas en el índice o si no, la consulta no usará dicho índice. Además, en los índices multicolumna si sólo hacemos referencia a uno de sus campos no usaremos el índice completo, por lo que hay que tener muy claro cuando definir un índice de este tipo en vez de uno simple. Hablaré sobre este tema de nuevo en la parte de optimización SQL.

Define una hoja de estilos y mantenla siempre

En algunos casos, como MySQL, hay diferenciación entre mayúsculas y minúsculas en el nombre de las tablas, es por ello que viene bien definir un estándar a la hora de ponerles un nombre: Todas en mayúscula o en formato camelCase. Tampoco es recomendable utilizar caracteres especiales a la hora de nombrar tablas o campos.

Si todos los campos se deciden nombrar en singular, esto tiene que ser así siempre. Por otra parte, si estas desarrollando una aplicación que puede ser utilizada por gente de otros países es recomendable usar siempre nombres en inglés.

Resumiendo, márcate tu propio estándar o usa uno ya existente, pero sigue ese estándar a muerte.

Las reglas que yo suelo usar, pero que pueden ser perfectamente otras, son las siguientes:

  • Separa las palabras a partir de un guión bajo o siguiendo el estilo camelCase. En mi caso prefiero la primera opción.
  • Nombra la tabla y los campos en singular.
  • Si tienes muchas tablas que pueden ser agrupadas en grupos lógicos, utiliza un prefijo que te ayude a identificarlas.
  • Intenta que los nombres sean descriptivos y evita abreviaciones, pero sin que sean demasiado largos.
  • Los campos Primary Key deben empezar por el prefijo ID.
  • Primero se crearán los campos PK, seguidos luego de las FK.
  • Escribir todo en mayúsculas o minúsculas. En mi caso soy más de la primera opción.
  • No utilizar caracteres numéricos, al menos en el nombre de las tablas.
  • Los campos que estén en varias tablas (como las FK) deben tener el mismo nombre.

Bueno, con este post ya acabamos la parte de Diseño de Bases de Datos. En la siguiente pildorita vamos a empezar ya un poco con la sintáxis SQL, ¡así que estaros atentos!

Índice de Pildoritas

Share
9
Mar 13

El Día de la Mujer Trabajadora y el porqué de que siga siendo necesario

_wecandoit_83c2ff46Ayer 8 de Marzo fue el Día de la Mujer Trabajadora. En los últimos años he visto muchos hombres (afortunadamente son minoría) “indignados” por la celebración de este día y que reclaman también un día para el hombre trabajador, ya que parece que el 1 de Mayo no les parece suficiente.

Yo desearía que no hiciera falta celebrar el día de la mujer trabajadora, como también desearía que no tuviéramos que celebrar el día del orgullo gay. Pero mientras haya colectivos que sufran discriminación por su propia condición sexual estos días son necesarios.

El día de ayer sirve para recordarle a toda la sociedad que sólo el 53% de las mujeres españolas está en el mercado laboral, de las cuales un 26,5% está en paro. A su vez, 40.000 españolas trabajan a tiempo parcial, mientras que los hombres con este tipo de jornada son sólo 15.000.

Las mujeres europeas cobran de media un 15% menos que los hombres, siendo mayor la brecha en España, donde la diferencia es del 21,9%. Además, el 8,1% de las mujeres españolas tienen ingresos inferiores al salario mínimo interprofesional, frente a un 2,9% de los hombres.

Algunos de estos datos que menciono son de Febrero de 2011, y hay que decir que la brecha salarial ha disminuido ligeramente, pero esto no se debe a que las mujeres ahora cobremos más, sino que los salarios de los hombres han descendido notablemente. Para datos más actuales os recomiendo esta noticia del diario.es, Cinco gráficos sobre la situación de las mujeres

Este último año estamos viendo un resurgimiento del machismo en España. Con leyes discriminatorias con la mujer, como la ley del aborto de Gallardón, o la salida de tiesto del Diputado de UPyD Toni Cantó, hay que callar las soflamas populistas y engañosas con datos puros y duros.

Creo que con los pocos datos que he recogido en este post ya se justifica por sí sola la existencia de un día de la mujer trabajadora. Aunque hemos mejorado notablemente en los últimos 30 años con este tema, todavía queda mucho trabajo por hacer y es por ello que viene bien que durante un día al año recordemos el largo camino que queda todavía por caminar en esta materia.

Cuando estas brechas laborales entre hombres y mujeres desaparezcan, el día de la mujer carecerá de sentido, pero hoy por hoy, todos los días deberían ser el día de la mujer trabajadora.

todos_los_dias_son_8_de_marzo

Enlaces relacionados:

Share
5
Mar 13

La España del Lazarillo

Acaeció que, llegando a un lugar que llaman Almorox, al tiempo que cogían las uvas, un vendimiador le dio un racimo dellas en limosna.

Acordó de hacer un banquete, así por no poderlo llevar como por contentarme: que aquel día me había dado muchos rodillazos y golpes. Sentámonos en una valladar y dijo:

-Agora quiero yo usar contigo de una liberalidad,y es que ambos comamos deste racimo de uvas y que hayas de él tanta parte como yo. Partirlo hemos de esta manera: tú picarás una vez y yo otra, con tal que me prometas no tomar cada vez más de una uva.

Yo haré lo mismo hasta que lo acabemos, y de esta suerte no habrá engaño.

Hecho así el concierto, comenzamos; mas luego al segundo lance, el traidor mudó propósito, y comenzó a tomar de dos en dos, considerando que yo debería hacer lo mismo. Como vi que él quebraba la postura no me contenté ir a la par con él; más aún pasaba adelante: dos a dos y tres a tres y como podía las comía. Acabado el racimo, sostuvo un poco el escobajo en la mano, y, meneando la cabeza, dijo: -Lázaro: engañado me has. Juraré yo a Dios que has comido las uvas de tres a tres.

-No comí -dije yo-; mas, ¿por qué sospecháis eso?

Respondió el sagacísimo ciego:

-¿Sabes en qué veo que las comiste de tres a tres?

-En que comía yo dos a dos y callabas."

Share