Una de normalización y otra de MYSQL o PostgreSQL

[urjose]

Pues estoy con el dilema siguiente:

1.- Tengo a cargo la migración de una BD de SQL Server a otro manejador MySQL o PostgreSQL

• Son 10000 usuarios
• Son miles de registros de empresas publicadas en el directorio
• Son miles de productos que transportar.

Ahora bien, el portal tiene alrededor de 4000 visitas diarias. Que manejador utilizarian ustedes?

MySQL -> Gran performance
Postgres - > Mas lento pero con Triggers, Store procedures, peroo menos rápido.

2.- Hasta que punto debo normalizar, por ejemplo normalizando correctamente tendría algo así:

Tabla Usuarios

id_usuario | nombre | id_pais | tipo_empresa

Tabla Paises

id_pais | nombre_pais


Tabla TipoEmpresas

id_tipo_empresa | tipo_empresa

Si ven la idea, normalizando demasiado crearia muchos joins, pero si no normalizo, guardaría por ejemplo en cada campo el nombre del pais y un tipo de empresa.

Que creen que sea mas eficiente?

3.- Si conocen algun hosting confiable con PostgreSQL favor de notificarlo.

Saludos y gracias

[Webstudio]

Urjosé, pues la verdad que sobre PostGres conozco poco y nada, sobre eso podría ayudarte Ferdy, por ejemplo, que ha trabajado mucho más con esa base de datos. Yo personalmente siempre trabajé con mySQL, hoy mismo estoy trabajando con una base de datos mySQL sirviendo 5 portales diferentes que suman, entre ellos, 270000 pageviews diarios, con una programación MUY poco optimizada (en palabras simple, un asco de programación), y la verdad que mySQL no se queja por el momento. Y sobre Triggers y Store Procedures, que quieres que te diga? debo llamarme suertudo porque nunca tuve en realidad necesidad de utilizarlos.

Una sola pregunta quería hacerte, el campo tipo_empresa dentro de la tabla de Usuarios, corresponde a la descripción del tipo de empresa, o al id (id_tipo_empresa) de la Tabla TipoEmpresas ?

si fuera la descripcion : te faltaría un paso más en la normalización y es reemplazar la descripción por el Id del tipo de la empresa.

si fuera el Id : a veces por mera costumbre o nomás para simplificar luego los querys, es mejor que los nombres de los campos sean siempre iguales, por lo que yo le pondría id_tipo_empresa.

Por ejemplo, si no tuvieran el mismo nombre, un JOIN sería asi :

SELECT u.* FROM Usuarios u LEFT JOIN TipoEmpresas t ON u.tipo_empresa = u.id_tipo_empresa;

no es un query muy complicado, pero si tuvieran el mismo nombre, se facilitaría un poco más :

SELECT u.* FROM Usuarios u LEFT JOIN TipoEmpresas t USING (id_tipo_empresa);

Espero que te sirva.

Saludos !

[urjose]

Una sola pregunta quería hacerte, el campo tipo_empresa dentro de la tabla de Usuarios, corresponde a la descripción del tipo de empresa, o al id (id_tipo_empresa) de la Tabla TipoEmpresas ?

Hi, gracias por responder. Es el Id, o sea es una llave foranea. Solo que es un ejemplo y no me fije bien en los nombres jeje

Ahora el dilema es si es mejor normalizar o guardar directamente por ejemplo el tipo empresa.

Hagamos de cuenta que esa tabla Paises y TipoEmpresas son catalogos, pues de esas son como 11 tablas o sea tengo 11 tablas de catalogos, los cuales estoy en el dilema de realmente normalizarlas o guardarlas directamente en las tablas que las necesitan.

Saludos

PD. Creo que utilizare MySQL por que no encuentro ningun hosting con PostgreSQL decente.

[Webstudio]

Mirá, a mi siempre me gustó tener las tablas lo más normalizadas posibles dentro de la practicidad de lo que se pretende hacer.

Qué quiero decir con esto ? Simple, en tu caso, por ejemplo, si en vez del Id del Tipo de la empresa, pusieras directamente el Tipo de la Empresa ( el nombre ), al comienzo no tendrías problema.
Pero supongamos que tienes suerte y tu base de datos comienza a crecer, y llegas a unos 500.000 registros ( en algunas aplicaciones es impresionante lo rápido que llegas a estos números ).

Aquí es dónde comienzan los problemas, porque un TipoDeEmpresa, necesita cambiar el nombre, en vez de hacer 1 update en 1 tabla, tenés que hacer un update masivo que abarcará unos 500.000 registros, con los consiguientes actualizaciones de indices, lockeos de tablas ( o con suerte, de columnas o de filas ), etc. Mucho "overhead" por algo que deberia haber sido más sencillo.

En estos casos es cuando recomiendo Normalizar.

¿Y cuándo NO normalizar? Bueno, cuando los efectos de una normalización, son más nocivos que benignos para el resultado el Script en si mismo. Uno de los pasos de una normalización ( el primero creo ) es eliminar todos los campos que pueden ser calculados en base a otros. Este es el típico ejemplo del total de mensajes de un Foro.

Según las reglas de normalizacion, si quisieramos saber la cantidad totales de mensajes de un foro, tenemos que recorrer todos los temas de cada foro, contando los mensajes que tienen, y su hubiera subforos, habría que hacer lo mismo con cada uno, entrando recursivamente dentro de cada sub foro. Demasiado no ?

Eso se soluciona TAN fácil, saltándose una regla de la normalización, que es agregando un campo extra llamado TotalMensajes que se vaya actualizando cada vez que se borra o se crea un nuevo mensaje. Luego solo leemos el contenido de esta variable y listo.

Bueno, esto es en base a mi experiencias con bases de datos, que es bien poca. Si alguien quiere agregar algo más, que se me pueda estar escapando, bienvenido sea.

Saludos.

[delfiero]

Me gustaría añadir algo respecto a cuando utilizar Postgres y no Mysql.

En mi humilde opinión nadie discute que Mysql es más rápido per Postgres (a nivel consulta).

Pero entonces, cuando hay que utilizar Postgres?
Una buena razón es cuando la integridad de los datos es fundamental, y esta se puede romper por los acessos de usuarios que comparten y actualizan los mismos datos.

O sea, que si el proyecto tiene muchos acesos pero a nivel de consulta, yo creo que Mysql tirará tranquilamente, e incluso mejor que Postgres.

En cambio, si hay mucha concurrencia de usuarios contra datos, y estos son compartidos (distintos usuarios acceden a la vez, y pueden modificar datos los datos compartidos entre todos), entonces la integridad de las transacciones se convierte en fundamental. No creen?