poner restricciones a la hora de meter datos

[usuario90210]

Hola,

Estoy mirando y n encuentro nada parecido. Aver, el problema es que quiero poner restricciones a la hroa de que metan datos. PAra que se entienda, tengo un campo fecha, y y quiero que cuando la tienda y el producto sea el mismo, mira la ultima fecha que hay metida y que solo le deje meter datos si la fecha es siete dias mas que la ultima fecha que esta metida para esa tienda y producto.

Asiq, lo que haria es hacer una consulta que me saque la ultima fecha de cada tienda y producto. y que no me deje meter para esa tienda y producto si la fecha es mayor o menor de siete.

Espero que se entienda.

Un saludo y gracias!

[gnzsoloyo]

Ese nivel de validaciones no se debe realizar en la base, sino en la aplicación. Pierdes menos tiempo y es más eficiente.
Yo tengo aplicaciones cuyos formularios sólo se activan sobre la base de parámetros leidos en la base de datos al momento de ir a mostrarlo. Estos formularios, cuando van a mostrarse realizan la consulta a la base por los parámetros de validación y luego los siguen usando mientras el formulario siga a ctivo.

Recuerda que el SQL es un lenguaje de consultas, no de programación.

[Valery-Net]

gnzsoloyo no estoy de acuerdo con lo que comentas, que pasa si alguien ingresa a la base de datos y edita el registro?, lo permitiría debido a que las restricciones están establecidas a nivel de la aplicación, debes tener en cuenta que si la validación la colocas en un "desencadenante" en la base de datos no permitirá que a nivel de aplicación o de base de datos se pueda ingresar el registro

[gnzsoloyo]

que pasa si alguien ingresa a la base de datos y edita el registro?

Si te pasa eso, tienes un serio problema de seguridad. Las bases de datos sólo deben ser accesibles por las aplicaciones y no manualmente, a menos que seas DB Developer o DBA.

lo permitiría debido a que las restricciones están establecidas a nivel de la aplicación

No. Los usuarios de una aplicación tienen que tener niveles de permisos asignados y sólo deben comunicarse con la base a través de la aplicación.
¿Por qué querrías darle otro nivel de permisos? ¿Para qué querrías permitir que hagan otra cosa que lo que tu les permites hacer?

Yo no le permito a los usuarios de mis aplicaciones que accedan directamente, y si lo hacen, se encontrarán que no pueden ejecutar ni un simple SELECT. Además, si lo hacen desde la aplicación, las mismas consultas van validando contra las tablas de permisos si el usuario puede ver información.
La seguridad de una base lo es todo en ciertos niveles.
No se le puede permitir a alguien por fuera que entre y te haga un DROP TABLE... ¿no te parece?

[Valery-Net]

Conoces acerca del desarrollo en capas ?

Yo tengo muchas razones para esto y te las voy a detallar:

El hecho de descargar lógica del lado del cliente suele ser hasta peligroso, adicionalmente las aplicaciones se hacen mas complejas de programar y mantener. Usando desencadenadores como solución se esta reutilizando código implícitamente, cualquier aplicación que acceda a una tabla existente tendrá las restricciones, será validada sin necesidad de escribir una sola línea de código de más.

Además, hay que tener en cuenta que si el sistema es accedido a través de Webforms no será bueno cargar al cliente de trabajo que se debería concentrar del lado del servidor.

De igual forma cada quien mata los piojos como le parece.

[gnzsoloyo]

Conoces acerca del desarrollo en capas ?

Si. Conozco y trabajo desarrollando en capas.
Pero también soy DBA en 3 DBMS, lo que hace que mi visión sea algo diferente de la de los developers y de los programadores.

El hecho de descargar lógica del lado del cliente suele ser hasta peligroso, adicionalmente las aplicaciones se hacen mas complejas de programar y mantener.

Mi afirmación no tiene nada que ver con descargar la lógica hacia un lado y hacia otro. Mi afirmación se basa en que es absolutamente inútil y representa una carga ineficiente realizar validaciones de datos elementales dentro de la base de datos. Establecer si un valor debe ser 1, 2, 5, 8, ó 14, no requiere SP ni TRIGGERS a nivel de capa de datos, sino verificaciones en la capa de negocios... Lo que sí debe hacer la capa de datos restringir los datos a los valores lícitos en determinados campos, lo que tiene que ver con el dominio dado a ese atributo al momento de diseñar la estructura física, y no necesariamente a procesos de validación en rutinas.
¿Para qué esperar que un TRIGGER o un SP te devuelvan un error, si lo puedes capturar antes?
Lo que decía que hago es que en la capa adecuada se carguen los valores que una instancia de un dato puede tener, es decir, tratar de hacer que los Forms (Web o Win) sean lo más a prueba de idiotas que se pueda.

Además, hay que tener en cuenta que si el sistema es accedido a través de Webforms no será bueno cargar al cliente de trabajo que se debería concentrar del lado del servidor.

Si. Es cierto, pero el problema no es cargar al cliente lo que le corresponde, sino cargarle lo que el cliente tiene más recursos para lograr... y los lenguajes de programación tienen muchas cosas que hacen mejor que la BBDD.

[huesos52]

Perdón que meta la cucharada... Estoy de acuerdo con ambos. Pensando como desarrollador y como minidba que apenas empiezo en este mundo.

Yo tengo una base de datos en postgresql y tengo 5 roles dentro de la misma. Estos usuarios están autorizados para crear funciones, procedimientos triggers etc. pero no para alterar tablas ni crear nuevas. Nada gano con impedirles permisos de actualización, ni inserción, porque podrían hacer una función que hiciera eso por ellos.

A nivel de base de datos, utilizo check constraints para validar los rangos de datos validos para un campo e impedir que alguien de mi grupo de trabajo pueda hacer actualizaciones o inserciones que hagan perder la consistencia y sentido del sistema(Datos de investigación). En este caso son totalmente necesarias las validaciones de entrada de datos controladas desde el dbms.

Por otro lado, estoy de acuerdo con gnzsoloyo explicitamente con esta frase:

¿Para qué esperar que un TRIGGER o un SP te devuelvan un error, si lo puedes capturar antes?

Si el error se puede evitar a nivel de aplicación, por que dejar que el sistema realice un viaje inoficioso a la base de datos para traerse una respuesta negativa?

En conclusión, dependiendo de la situación es mas optimo y necesario la validación de datos a nivel de base de datos y para otros casos a nivel de aplicación.
Para el problema de usuario90210 es mejor controlar esto desde la aplicación.

Es mi opinión.

[gnzsoloyo]

Totalmente de acuerdo con la conclusión. Bien expresado.

Saludos.