PHP y dB: Otro dilema conceptual

[Calisco]

Hace un tiempo estoy haciendo una pagina para una liga de Paddle, y es bastante 'enredada' toda la administracion. Estoy usando POO=)
Me refiero a que hay temporadas, divisiones, fechas de temporadas, parejas de juego, ranking, resultados de partidos, etc, etc, etc ...

Todas as estrcuturas de las tablas estan relacionadas entre si a travez de ids.
Actualmente trabajo, como todo hujo de vecino, con MySql.

EL tema es algunas consultas de datos son bastante enredadas, y mas de una vez utilizo codigo PHP para lograr obtener los datos necesarios.

1) Es mejor, SIEMPRE, tratar de realizar tolas las consultas en lo posible con el motor MySql o a veces conviene 'relacionar' las busquedas con codigo PHP ?

2) Es conveniente agregar informacion redundante a las tablas para hacer las busquedas mas sencillas, a costo de mas informacion ?

No se si se entiende.
Saludos.

[SiR.CARAJ0DIDA]

con respecto a la 2da pregunta, se supone que en una base de datos nunca hay datos repetidos, ya que los puedes sacar de las otras tablas mediante joins. no se si es eso exactamente lo que preguntas.

[Cluster]

Por mi parte siempre apuesto por que vía SQL se obtenga todos los datos que requieres de tu modelo de datos. El "tamaño" siempre puedes adquir más en tus servidores si lo necesitas, el proceso de SQL por parte -solo- de tu motor de BD normalmente es más rápido y limpio para tu aplicación que mezclar PHP por médio. Imagina por ejemplo si tienes que migrar tu aplicación a otro lenguaje o hacer algún módulo en otro lenguaje que se base en datos de tu actual modelo de datos.

El tema de añadir más información "redundante" .. mm si el modelo de datos (tus BD .. sus relaciones .. etc) lo haces bien .. no tendrías por qué añadir información redundante, en tal caso aprender más SQL para implementar la sentencia SQL adecuada, e .. incluso puede sucederte que por las características del motor de BD que usas (actualmente dices Mysql).. este se te quede "corto" .. me refiero por ejemplo: taréas rutinarias de consultas SQL complejas .. podrías usar "store procedure" cosa que no soporta Mysql hasta su versión 4.1 si mal no recuerdo pero que los dispones en otros como PostgreSQL, MS SQL server .. etc.

Un saludo,

[HerSAn]

Asi a simple vista pueden estar pasando dos cosas y una es que no tengas un buen modelo de datos por que tu analisis no fue lo suficiente, para ver detalles que ahorita te estan pegando en la programacion, en mi opinin no deberias estar manipulando datos mas de la cuenta en tu script de lo que se debe es mas facil y limpio hacerlo desde mysql y la redundancia lo unico que te generara es inconsistencia entre tus tablas y el costo de informacion inecesaria en tu modelo. Ahora es posible que al hablar de manipulacion en php te esten refiriendo a la implementacion de las reglas de negocio y hay como comenta cluster puedes usar procemientos almacenados y disparadores que no implmenta mysql del todo en este momento y que se hicieron para lo que comente, implementar reglas de negocios.

Pero antes de ver si necesitas migrar a otro RDBMS seria conveniente que hagas un reanalisis mas detallado de tu problema y que crees un modelo de negocio que se acerque mas a la realidad de lo que necesitas, que revises tus objetos y sus responsabilidades, colaboraciones, si necesitas implementar mas de un patron de diseño para lograr lo que necesites. e insisto con el analisis, por que desde hay te das cuenta de la arquitectura que necesitas y las aplicaciones mas idioneas para llevar acabo el proyecto, como plataforma, base de datos, lenguaje, etc... Y es posible que en tu caso solo te falte replantear el problema y ya cuando lo analises bien te daras cuenta si estas implementando en el lenguaje correcot y con la BD correcta y demas..

Saludos.

[jpinedo]

Iniciado por HerSAn

(...)la redundancia lo unico que te generara es inconsistencia entre tus tablas y el costo de informacion inecesaria en tu modelo(...)

Hola Herminio:
En mi opinión, a veces la información redundante nos puede permitir reducir algunos costos. La conveniencia de redundar siempre depende de la relación lectura/escritura de un dato.

Un ejemplo muy simple: Podríamos considerar redundar la fecha y hora del último mensaje de los temas de un foro en lugar de calcularlo cada vez. Si bien perdemos recursos durante la inserción de un nuevo mensaje (porque hay que insertar el dato fecha/hora en dos tablas en lugar de una), también ahorramos mucho en el momento de cada lectura.

Aquí es evidente que habrán muchísimas más lecturas que escrituras (con una relación muy alta), así que se podría considerar la redundancia como apropiada. Eso sí, siempre que haya un buen control de consistencia.

Saludos

[Calisco]

Ok, la verdad que por lo menos me han marcado un sendero en la complejidad de mi diseño. No puedo (podria) explicar los detalles necesarios para el diseño del sitio que estoy haciendo ya que seria aburrido y creo que tampoco es el punto.

Mas adelante voy a poner las estrucutras de las tablas y las clases que diseñe.

Otra pregunta: Que es Store Procedure ?. Seria algo asi como consultas anidadas ?, porque creo que la ultima version estable de MySql ya cuenta con esto.

[HerSAn]

Iniciado por Calisco

Otra pregunta: Que es Store Procedure ?. Seria algo asi como consultas anidadas ?, porque creo que la ultima version estable de MySql ya cuenta con esto.

No, lo que comentas son los subquerys, los store procedure se estan implementando para las versiones 5.x de mysql, y bueno en realidad son conjuntos de instrucciones sql que estan dentro de un bloque y que se almacenan en el servidor, pueden ser implementados mendiante puro sql u otor lenguaje, mysql implementara el primero. Y bueno te sirven para reducir el costo de algunas operaciones que de otra manera cargarian tu programacion. Tambien existen los trigger que se almacenan junto con las tablas y que son llamados cuando ocurre un evento sobre la misma, estas dos herramientas pueden ayudarte a mejorar la aplicacion que estas desarrollando por eso cluster recalco el echo de que analizaras si mysql cumplia con tus necesidades.

Ahora sobre la redundancia, los costos son mas altos que solo escribir y leer, y si el modelo que esta desarrollando calisco es de mas lectura que de escritura no veo la necesidad de tener redundancia lo que habria que ver que datos tiene que ser realmente persistentes.
Estoy de acuerdo que la redundancia no desaparece totalmente de los modelos de datos pero para eso se hicieron las reglas de normalizacion para reducirla, y mejorara la lectura y la escritura de datos. la redundacia puede parecer aplicable en algunos casos pero en genral, al menos yo, no la recomiendo es preferible crear buenos modelos.
ahora habria que ver jpinedo que estas considerando como redundante, ya que se supone que la redundancia es cuando hay conjuntos de datos que se repiten para la misma clave. o si prefieres tuplas que tienen la misma informacion para la misma clave.
En cuanto al ejemplo, habria que ver bajo que condiciones lo estas tomando para ver si realmente estas redundando datos o no.
Me gustaria que comentaras este echo igual estamos viendo puntos diferentes o estamos tomando el termino en diferente contexto. Ya que le veo mas problemas que beneficios a la redundancia.

Saludos.

[Calisco]

Ok, gracias.

[belen_lmvc]

Hola Cluster, por casualidad a lo que te refieres con "proceso SQL" es lo mismo que "procedimiento remoto" de sql server?.

Te hago esta pregunta porque donde trabajo, usan ASP/VScript y SQL Server de tal forma que todas las consultas a la BBDD, las realizan a través de llamadas desde VBScript a procedimientos remotos que se encuentran en la base de datos.

Este mismo proceso se podría realizar en PHP?

Saludos

[Casuis]

Hola a todos hace poco me toco hacer la tediosa tarea de mantener un proyecto parecido a una liga en fin... El problema era q la base de datos estaba muy mal diseñada y utilizaba anidamientos desde php, ningun problema siempre y cuando compruebes el casting pero yo creo q eso no es tarea para el codigo sino para la base de datos, total que se tubo que hacer el proyecto de nuevo (se pudo aprovechar los datos jeje) y solo por no asegurarse la integridad referencial, y como es eso?

Bien en mysql ahora(hace un tiempo) podemos utilizar el tipo de tablas INNODB en contra de MYISAM,
las INNODB son más lentas que las MYISAM pero soportan transacciones y se pueden referenciar es decir, el tipico foreign key con modalidades on delete cascade/null ...
es decir podemos conseguir integridad referencial asi q si lo hacemos bien podemos pasar al codigo sin tener que preocuparmos más por la base de datos.

-- STORE PROCEDURES --

Los Store Procedure la version 5 de mysql ya la incorpora aunque si lo que quieres es utilizarlos con más robustez puedes migrar de mysql a postgresSQL. El inconveniente principal de los Store Procedure es que son dependientes de la base de datos, es decir la programación en Oracle será diferente a DB2 o postgresSQL así que si trabajamos con ellos tendremos que tener en cuenta que nos hacemos dependientes de la base de datos... en fin procesaremos más rápidos los datos pero seremos más dependientes del sistema gestor de BBDD.

[javier_enithost]

Hola :

Pues considero firmemente que nunca se debe redundar informacion. El hecho de redundar informacion puede traer consigo inconsistencia de informacion porque tienes informacion redundante que bajo cierta circunstancias pueden dejar de estar "pareadas" o "sincronizadas" ( servidores con cargas excesivas, etc... ).

La teoria de normalizacion va en contra de esto, se recomienda siempre utilizar DBs ( o disennar DBs ) en 3ra forma normal como minimo.

Sobre el uso de stored procedures pues comentare que actualmente la version estable y de mejores resultados de mysql es la 4.x; esto es un criterio muy personal basado en mi experiencia.

Esta version permite el uso de tablas INNODB que permite operaciones atomicas o transaccionales por lo que garantizan integridad referencial ( o actualizacion/eliminacion de campos en cascada ); teniendo esto en la mano y haciendo un buen disenno de la DB estoy seguro que podran hacer de todo, no importa cuantas tablas necesiten crear en la DB para la capa de datos de su problema.

Saludos