¿ Procedimientos almacenados ? ¿ Como crearlos ?

[chemajmb]

Buenas,

Un amigo me aconsejo hacer procedimientos almacenados y llamar desde php a estos. También creo que me dijo que se traía todos los campos de una tabla por que era mas rápido o mejor no se exactamente por que.

Me gustaría saber si esto es así y por que.

Me disponía a crear mis primeros procedimientos almacenados pero tengo estas dudas.
Había pensado en pasar 4 parámetros, uno con un array con los campos del select, otro con el where, otro con el orderby y otro con el limit.

Por cierto, ¿ un truco para pasar arrays multidimensionales ?

Gracias.

[gnzsoloyo]

Depende del DBMS.
Si vas a usar MySQL, no admite arrays porque no existen los datos de tipo array en MySQL
En otros, como por ejemplo Oracle, si existen.
No te olvides que la base de datos no interpreta PHP y que es algo completamente independiente de los lenguajes de programación que la usan. Las bases de datos sólo entienden SQL.

Por otro lado, no existe un lenguaje PL/SQL estandarizado, por lo que uno escrito para SQL Server no funciona en Oracle, y uno de Oracle tampoco funciona en Postgre o MySQL.
Cada DBMS les pone cosas propias, especialmente a los SP.
Por desarrollo de SP te conviene preguntar en el foro del DBMS que usarás.

[chemajmb]

EDIT:
Buenas,

Estoy trabajando con PHP y MySql.
Un amigo me aconsejo hacer procedimientos almacenados y llamar desde php a estos. También creo que me dijo que se traía todos los campos de una tabla en vez de traerse un determinado número de campos por que era mas rápido o mejor no se exactamente por que.

Me gustaría saber si esto es así y por que.

Me disponía a crear mis primeros procedimientos almacenados pero tengo estas dudas.
Había pensado en pasar 4 parámetros, uno con id del rol del usuario para saber que campos tiene acceso y simplemente traerme estos campos, otro array con las condiciones del where, otro array con el orderby y otro con el limit.

Por cierto, ¿ un truco para pasar arrays multidimensionales ?
http://quinqui-bitacorita.blogspot.c...ametro-de.html
Aquí encontré uno pero es solo para una dimensión pero creo que me puede valer.

Pero se admiten otros consejos.

Gracias.

[gnzsoloyo]

¿Entendiste que MySQL no te podrá recibir un parámetro que sea un array?
Simplemente no lo entenderá.

También creo que me dijo que se traía todos los campos de una tabla en vez de traerse un determinado número de campos por que era mas rápido o mejor no se exactamente por que.

Porque evitas traer basura que no usarás. Y también evitas procesar en la base datos que no vas a utilizar.
Es una cuestión de performance.

[Synkronice]

Hola Chemajmb,

Para consultar sobre como crear procedimientos almacenados es mejor que preguntes en el foro de MySQL ya que es en la bbdd donde se programan.

Por otro lado mi consejo y recomendación es que lo programes como tu te sientas más cómodo. Tu amigo quizás tenga razón pero si no dominas MySQL creo que meterte a programar procediientos almacenados puede ser más un dolor de cabeza que otra cosa.

Yo llevo 10 años programando y aún no he tenido la necesidad de crear procedimientos almacenados.

Si lo que tienes entre manos es un proyecto pequeño no hace falta que te compliques tanto. Si vas a desarrollar la web de un banco que va a tener 1000 visitas por minuto entonces si preocupate en programar con procedimientos almacenados.

1abrazo y felices fiestas,

Synkronice

[chemajmb]

Si, si que lo entendi, hasta ahi llego, jejeje, simplemente no existe ese tipo de datos en mysql.
Es por eso que preguntaba por alguna solución como la que dan en el enlace que puse.

También me interesa mucho como implementar el control del acceso de los usuarios con un determinado rol a los campos de las tablas de la base de datos.
Bueno, vamos a ver, si se como implementarlo, las tablas que tengo que crear y eso.
Lo que no se es que es mejor si aplicar la restricción en las consultas o en el php.
Es decir, si me creo consultas que me traigan ya exactamente los campos a los que tiene acceso ese usuario o si me traigo todos los campos y en el php hago la restricción.

Muchisimas gracias por tu pronta respuesta y tu cordialidad.

PD: Siento haberme equivocado posteando y dar trabajo a los administradores. Esperare un poco a ver si un admin mueve el hilo. Y si no lo mueve y no consigo repuestas quizas empiece donde me habeis dicho otro hilo. Perdon.

[gnzsoloyo]

La solución que propone ese link es un parche bastante malo e ineficiente. Al menos el segundo de los ejemplos.
El primero es parcialmente implementable, pero para hacerlo tienes que usar funciones de MySQL (que no dominas), o bien sentencias preparadas (que tampoco dominas)
Es mucho más sencillo realizar esas cosas de otra forma, al menos en lo que alos Sp se refiere.
Postea el tema en el Foro de MySQL y lo vemos.

[chemajmb]

@Synkronice lo que me dices respecto a los procedimientos almacenados encaja perfectamente con el contexto de mi amigo, pues el desarrolla programas bastante complejos en .NET. Como despues de este proyecto de PHP y Mysql me pondre con .NET, creo que sera mucho mas productivo empezar entonces con los procedimientos almacenados, que aprenderlos en mysql para este único proyecto.

[chemajmb]

Hola a todos, un placer.

Estoy desarrollando una aplicación MVC en PHP y MySql y tengo dudas acerca de como implementar el ACL para controlar el acceso a los campos de las tablas de la base de datos.
Ahora estoy con la parte de administración, con los listados, es decir, cada usuario vera en la interface una tabla con un listado de las columnas de la información de cada "entidad", ya sea categorías, productos, pedidos, facturas, ... ( con entidades me refiero a las entidades del proyecto, no a las tablas de la DB, es decir una entidad puede estar formada por varias tablas de la DB )

Lo que necesito es que alguien me diga si voy por buen camino en la manera de como tengo en mente desarrollarlo. Y si no voy por buen camino me diga otras soluciones o por que lo estoy haciendo mal.

Lo que yo tengo en mente hacer es en las consultas para listar que yo hago en los métodos de los modelos, chequear los privilegios del usuario ( osea su rol ), y entonces traerme de la DB únicamente las columnas ( campos ) a los que tiene acceso. No se si esto se hace así o de otra manera. Necesito que alguien me oriente una buena manera de hacerlo.

Claro, esto se complica un poco o al menos eso me parece, si la consulta select para el listado de la "entidad", accede a campos de distintas tablas, como por ejemplo la entidad factura, deberemos acceder a la tabla de facturas y a la tabla lineas_de_factura.

En algún lugar tengo que hacer el filtro de los campos totales del listado de la entidad facturas con los campos que el usuario realmente tiene permiso a acceder.

No se si me explico. Espero que si, si no es así hacerme lo saber. Gracias.

[gnzsoloyo]

En el contexto de un desarrollo basado en MVC, la mejor opción es realizar todos los accesos a BBDD por medio de stored procedures. AL menos esa es la forma más segura, especialmente porque la administración de accesos que requieres es a los módulos de la aplicación, y no a los accesos de la base.
Haciéndolo de esa forma puedes no sólo restringir perfectamente los datos a los que el usuario accede, sino que además puedes restringirle absolutamente el acceso a la base de forma directa, ya que el uso de SP no erquiere permisos a tablas, sino sólo permisos de EXECUTE a nivel usuario de MySQL.
Ese tipo de privilegios a un usuario hace que si pudiese loguear en el servidor, todas las tablas y vistas fuesen totalmente invisibles para él. Incluso la edición de los SP estaría fuera de sus posibilidades, porque para ello se requieren otros niveles de permisos.
Yo trabajo en una empresa de gran tamaño, y su aplicación (Web) está diseñada precisamente de esa forma.
A nivel de programación, todos los lenguajes tienen recursos para usar los SP. En el caso de PHP, si es el que usarás, debes acceder usando la librería MYSQLI de PHP. En .Net, te conviene usar el MySQL Connector.Net, que puedes descargar de la web oficial.
Ahora bien, ¿qué práctica has tenido creando SP?

[chemajmb]

Gracias por tu respuesta.

He tenido practica nula utilizando sp pero algún día tiene que llegar la primera vez, ¿ no ? jejeje.

¿ Y no se podria solucionar simplemente creando una tabla para guardar las relaciones de los roles con los privilegios a las tablas/columnas ?

id_rol / id_tabla / insertar / modificar / eliminar / listar ... no se si se me olvida alguno

id_rol / id_columna / insertar / modificar / eliminar / listar ...


Los campos insertar, modificar, eliminar, listar, .. son simplemente booleanos, true o false.

También se podria hacer quizas con un campo de caracteres con el formato nombre_tabla.nombre_columna

id_rol / tabla_columna ( varchar )/ insertar / modificar / eliminar / listar ...

[gnzsoloyo]

¿ Y no se podria solucionar simplemente creando una tabla para guardar las relaciones de los roles con los privilegios a las tablas/columnas ?

Se puede hacer, pero con eso lograrás complicar mucho la construcción de las sentencias.
Es decir. Si las sentencias se deben construir de acuerdo al permiso de acceso a nivel programa, tendrás que generar en cada caso la sintaxis dinámicamente para cada usuario en curso. No es que no se pueda, yo lo he hecho en algunas aplicaciones, pero termina siendo excesivamente costoso en tiempo de desarrollo y pruebas.
En realidad en esos contextos lo que te conviene es establecer un conjunto muy bien definido de perfiles, y crear VIEWs en la base para cada perfil, en cada caso que se acceda a ciertas tablas. Como los permisos de lectura como usuario de BBDD se pueden dar para las vistas, podrías de ese modo restringirle también de ese modo la visualización de los datos.
A nivel de administracion de privilegios, al menos en MySQL, no puedes restringir el acceso a columnas específicas de una tabla. Si tienes permisos de SELECT sobre una tabla es sobre toda la tabla. De allí que sea mejor crear una vista por cada perfil en cada tabla que ese perfil use, donde sólo invoques las columnas que el perfil puede ver.

¿Se entiende el problema?

Por eso es más sencillo manejarlo por SP o VIEWs.
Además, los SP son invulnerables al sql-injection, en cambio las vistas no, porque operan del mismo modo que acceder a la tabla, y es allí donde se produce la vulnerabilidad.
Todo sistema con cierto nivel de seguridad, implementa los accesos a la base por SP.

[chemajmb]

Ok ok, muchas gracias, entiendo, o eso creo.

La cosa es que las vistas son dinámicas, imagina una aplicación con muchos roles o roles específicos.
Estoy utilizando Jquery.datatables con conexión ajax y claro paso Json con la información entonces tengo que pasar solamente la información a la cual debe de tener acceso el usuario para que se le muestre.

Entonces esta claro, lo voy a hacer con SP, además así voy aprendiendo.

A ver, te digo lo que yo tengo en la cabeza y si puedes me dices por favor si voy bien encaminado o debería hacerlo de otra manera.
Por ejemplo en un select ( listado ) ¿ En los procedimientos tengo que pasar como parámetro el usuario para al principio del código del procedimiento hacer una consulta para saber los campos a los cuales tiene acceso ?
¿ Y cuando ya se los campos a los que tiene acceso, entonces hago la consulta de listar y seleccionar todos los campos para ese determinado procedimiento ?

Muchas gracias por la ayuda.

EDIT:

A ver, mi amigo me ha dicho que lo haga con SP de la siguiente manera si no le he entendido mal.
un SP que le paso id_rol
entonces con una unica consulta me traigo todos los campos que quiero listar para los que id_rol tiene privilegio mirandolo en la tabla de permisos de columna
id/id_rol/ nombre_columna / insertar / modificar / eliminar / listar
y entonces me devuelve una tabla con el listado, con algunos campos en null que son los que no puede acceder por no tener privilegios, simplemente elimino esos campos y devuelvo la tabla con los unicos campos a los que tengo acceso.
o tambien pongo un valor por defecto ( por ejemplo @@3###Ç )en caso de no devolver por no tener acceso, para luego eliminar las columnas de la tabla con valor igual a ese valor por defecto @@3###Ç.