lógica en bases de datos

[guardarmicorreo]

¿es recomendable introducir lógica en la base de datos?

¿en qué situaciones es recomendable introducir lógica y en cuales no?

introducir lógica ¿depende más de su finalidad o hay unas recomendaciones genéricas para todas las bases de datos?

[quimfv]

Genérica tu pregunta!!!
Usar la lógica en general es una buena cosa.

Concretamente en la bases de datos y en especial en el modelo relacional es básico.

El estudio del modelo relacional parte de un conocimiento profundo de la teoria de conjuntos, si esa de primaria, y de la lógica de predicados te dejo tres links a la Wiki

https://es.wikipedia.org/wiki/Teor%C3%ADa_de_conjuntos

http://es.wikipedia.org/wiki/L%C3%B3...e_primer_orden

http://es.wikipedia.org/wiki/Normali...bases_de_datos

Luego no se que entiendes por "introducir lógica en la base de datos", pero usar la logica en el momento de diseñar y/o consultar una base de datos es fundamental.

[guardarmicorreo]

tienes razón. no me expliqué en algo concreto.

explico mi situación y mi duda.
a raíz de tener que realizar un buscador interno para una web me puse a
estudiar sql y mysql.

mi problema parte de que utilizando tablas innodb no puedo utilizar fulltext puesto que solo sirve para tablas myisam.
entonces me explicaron anteriormente que debo utilizar un ambiente híbrido entre una tabla myisam donde por ejemplo tenga el texto de un post y como las tablas myisam no soportan claves foráneas entonces debo insertar el id en el campo foráneo de la tabla innodb con triggers, así mantengo la integridad referencial.

hablando en otro hilo, no de triggers, un usuario me dijo que no era recomendable introducir lógica en una base de datos. en un videotutorial sobre base de datos el tutor explica que no es recomendable utilizar todas las funciones nativas de la base de datos para hacer una portabilidad más fácil.

entonces lógica hasta qué punto?

[quimfv]

El diseño de una base de datos apesar de tener unas normas generales que hay que respetar depende del uso que vas a hacer de la bbdd. Ademas hay soluciones válidas distintas para los mismos problemas.

no era recomendable introducir lógica en una base de datos

Sigo sin entender a que te refieres.

no es recomendable utilizar todas las funciones nativas de la base de datos

Esto es cierto a medias.

Primero debes tener claro que:

. Sql es un leguage de interrogación de bases de datos.
. Que existe un estandar de Sql que determina una serie de normas del lenguage y
. Que cada sistema gestor de bases de datos (SGBD p.e. mysql, oracle, Sqlserver, Informix...) usa su implementación de ese estandar,
. Que las funciones es donde hay mas diferencias entre los SGBD (la funciones nativas de tu video tutorial)
. Que tambien hay algunas diferencias, digamos, sintacticas en algunos SGBD

Luego si programas minimizando el uso de las cosas que diferencian el SGBD que estes usando conseguiras que tu codigo sea mas portable si en un futuro se debe ejecutar contra otro SGDB. Minimizar no suprimir, puesto que hay casos en los que no es posible.

El caso de los FULLTEXT es uno de los mas claros, creo, en donde hay implementaciones distintas en los SGBD.

Finalmente todo esto no tiene nada que ver con lo que yo entiendo por lógica.

[guardarmicorreo]

lógica me refiero a triggers.

¿utilizar lenguaje del lado del servidor como php para hacer el trabajo del trigger o utilizar el propio sgbd?

en otras palabras:

¿lo que se refiere al motor de la aplicación web con php y lo que se refiere al almacenaje de datos con mysql o todo con php y mysql lo utilizo exclusivamente para guardar los datos, no para procesarlos de ninguna manera?

[quimfv]

Ahora!!! Pues dependerá de si ves la posibilidad de que tu aplicación se vaya a cambiar de SGBD.

Si trabajas con objetos y vehiculas todas las peticiones al SGBD por un solo objeto, solo tendrás que tocar ese objeto. Obviamente todo lo que este en la bbdd deberás recosntruirlo en la nueva bbdd, tablas, vistas, triggers o procedimientos almacenados y datos... pero solo cuando tengas que cambiar de SGBD....

[gnzsoloyo]

Vamos a tratar e aclarar algunos conceptos...
Una de las principales cosas que aporta la integridad referencial es asegurarte a nivel estructural, que la consistencia de los datos se mantiene evitando problemas con las relaciones entre tablas. Pero ese aseguramiento no implica que le derives a la base la tarea de crear u obtener por sí misma (via rutinas en SQL) los datos necesarios para sostenerlas.
No.
El objetivo, en ese contexto, es impedir que el programador cometa errores de consistencia de datos, haciendo que la propia base contenga ciertas rutinas de verificación previas al almacenamiento.
Pero la responsabilidad de no enviar datos basura a la base sigue siendo siempre del desarrollador. Es él quien tiene que hacer todas las validaciones previas, y todas las consultas previas a la base, para obtener los datos necesarios para una inserción o actualización exitosa. No la base.
Eso es lo que se hace en las aplicaciones empresariales, porque no sólo puedes poner datos inconsistentes en una tabla, sino que mientras lo haces estás enviando datos basura, con lo que recargas al sistema e transacciones que están condenadas al fracaso, mientras que las operaciones válidas quedan en espera.
¿Se entiende la idea?

El hecho de que no exista interidad referencial con tablas MyISAM pone un problema adicional a los programadores: crear la secuencia de llamadas a la base que permita asegurarse que los datos que se almacenaron cumplen con los requisitos de integridad de cada caso. Pero eso no es tan complicado como parece.
Puntualmente, los TRIGGER no son una buena opción, porque en MySQL los TRIGGER sólo tienen como datos de entrada los propios de la tabla donde se realiza la operación. Nada más. Por ende, si los datos entrantes no son suficientes para realizar una verificación contra otra... ¿qué haces?
No sirve.
En versiones anteriores, no ea posible disparar un error funcional en MySQL en un TRIGGER, pero afortunadamente ahora si (ver SIGNAL en manuales recientes), por lo que se puede hacer ciertas validaciones, pero como dije, no se puede buscar datos, a menos que los propios valores de entrada sean suficientes para eeso.
Entonces qué camino se puede elegir?
Simple.
Lo puedes ver en má de un manual sobre desarrollos de capa de datos: Stored procedures.
Los SP son el modo en que se implementa lógica programada en una base de datos. Para eso se construyeron, pero no se usan porque si.
¿Cuándo conviene usarlos?
Cuando:
1) Tienes todos los datos suficientes para realizar la validaciones y obtencion de datos intermedios del insert .
2) Cuando no se requiera ninguna nueva interacción o decisión del usuario para realizar ningún otro paso.
3) Cuando lo único que se desee es obtener una respuesta de éxito o fracaso, sea esta un valor dado (codigo de exito) o bien un set de datos (tabla).
Nunca se usan para resolver cosas que los lenguajes de programación hacen mejor. Jamás.

¿Se va entendiendo la idea?

[guardarmicorreo]

creo que lo he entendido.

imaginemos que tengo dos tablas, una innodb y la otra myisam.

tipo innodb

Post:

id_post|titulo|autor|foranea_texto

tipo myisam

Texto

id_texto|texto (fulltext)

para mantener la integridad referencial debo construir algo que en el momento de que un usuario introduzca un nuevo post almacene los datos en Post pero el id de Texto lo almacene en la foranea_texto hubicada en Post.

el problema radica evidentemente en que cuando se ejecuta el insert no tiene un id_texto para relacionar porque el post no existe todavía.

otra opción es introducir el id al revés, es decir, el id_post en un campo que sin ser foráneo contenga el valor como si fuera foráneo del id_post.

el problema sigue persistiendo, no puedo crear una entrada a raíz de otra a la vez porque no existen ninguno de los dos.

entonces es ahí donde estoy totalmente bloqueado.

por eso me decidí a aprender sql y mysql y por eso estoy tomándome mi tiempo para aprender todo lo necesario y resolver el problema.

es la primera vez que oigo sobre SIGNAL, pero lo busco y no encuentro en el manual de mysql.

¿SIGNAL puede resolver este problema?
¿podrían darme algún enlace donde pueda leer al respecto?

no quiero facilidades ni código, quiero aprender y preguntar lo que no entienda.

muchas gracias por su ayuda y sobre todo por su paciencia conmigo :D

p.d.: estoy viendo todas las posibilidades que hay para tratar este problema que seguramente me servirá para futuros diseños de bases de datos.

[quimfv]

El problema principal que tienes es que myisam tampoco soporta transanciones con lo que otro elemento de seguridad lo pierdes.... pero tienes la función LAST_INSERT_ID() con la que puedes saber el ultimo id autoinc insertado, ademas este valor corresponde a la session actual, luego creo que es bastante seguro de usar... en tu caso.

Primero insertas el texto en la tabla myisam e inmediatamente obtienes el ultimo id de la session, con ese valor insertas en la tabla innodb en el campo donde iria la clave foranea.... si solo se puede tocar ese campo por este procedimiento tienes asegurada la integridad... obviamente si se modifica directamente la bbdd la perderás....

Ahora bien esa es una de las funciones que si algun dia cambias de SGBD deberás revisar...

Myisam no permite las relaciones (FK) pero eso no quiere decir que NO puedas relacionar tablas en una query.... incluso si son de motores distintos.... la restricción afecta a nivel de bloqueo de registros, el cual se hara como se haria, entiendo??*, en el motor menos restrictivo, en este caso myisam...

*@gnzsoloyo si nos acabas de ilustrar será bien recibido... como siempre

[gnzsoloyo]

es la primera vez que oigo sobre SIGNAL, pero lo busco y no encuentro en el manual de mysql.

Manual de referencia oficial de MySQL a partir de la versión 5.5,x... y te lo dije claramente:

(ver SIGNAL en manuales recientes)

¿En dónde estás buscando?

De todos modos el objetivo de esa sentencia es generar o administrar condiciones de error, no resolverte consistencias. La idea es provocarlo para que el trigger falle y la operación se cancele.

Pero el problema central es que te estás ahogando en un dedal de agua, no ya en un vaso.
Las ocsas no son tan complicadas, pero debes olvidarte un poco de la lógica de programación, porque la de datos es diferente (no es una exageración).
Si tienes una tabla de posts, y una tabla donde almacenas el texto del post, en realidad lo que has hecho es crear una tabla por razones funcionales, pero el contenido de esa tabla sigue siendo un atributo del post, y por tanto pertenece a él.
¿Qué quiere decir esto? Simplemente que el texto depende del post y por consecuencia lo primero que se crea es el post. Siempre.
Luego de creada la inserción del post, y recuperado su ID, recién entonces se inserta el texto en su tabla, con el valor del id delpost recuperado.
Ahora bien, ¿qué pasa si el primer insert falla? Simple: No se hace el segundo.
¿Y qué pasa si falla el segundo? Más simple aún: Se debe dar de baja el primer registro en forma directa y sin más trámite...
¿Por qué?
Porque falló toda la operación que se considera atómica: post + texto. O ambos, o ninguno.

Todo eso se hace en un stored procedure de modo que reciba lo parámetros mínimos (usuario, tema, texto, por ejemplo), y devuelva siempre un codigo que represente exito o fracaso, que bien podría ser simplemente el ID del post (positivo si es exitoso, cero o negativo si hubo error).

Obviamente, es fundamental que el id_post sea uno de los atributos de la tabla de textos de posts, y si la relación entre post y texto es 1:1, como parece ser, simplemente ese mismo campo se declara como PK de la tabla de textos (donde se campo no es autoincremental, por supuesto).

¿Se entiende?

[quimfv]

Bien ... con esta "lógica" eliminas incluso un campo puesto que el id del post (autoinc) y el id del texto (no autoinc) seran el mismo ....

[guardarmicorreo]

si pudiera os invitaría a una cena. me habeis quitado mucha paja mental. GRACIAS!!!! :)

os cuento.

había concluido que el usuario tenía que enviar los datos a la tabla post y texto y unirlos con el trigger, no estaba viendo que no tenía que hacerlo así, sino que primero insertar una tabla, y con el id asignado insertar en la segunda tabla.


ahora me siento tonto :) era más simple de lo que yo pensaba.

tienes razón gnzsoloyo, con esto he aprendido que la lógica de programación no es como la de datos.

ahora, es buena idea sumarle a la inserción un COMMIT para evitar errores de inserción de datos?

y con esto terminaron mis dudas.

de verdad GRACIAS!!!

[quimfv]

ahora, es buena idea sumarle a la inserción un COMMIT para evitar errores de inserción de datos?

El problema es que a la tabla MyIsam las transacciones se las pasará por....

[gnzsoloyo]

Traducción: Las tablas MyISAM no son afectadas por los COMMIT, porque ese motor de tablas no tiene transacciones.
Para manejar la consistencia deberás ser cuidadoso al programar, validar y verificar, además de (posiblemente) usar bloqueos de tablas, cuidando de no generar deadlocks.