[pvizcay]

hola gente del foro, estoy desarrollando una aplicación contable D7+IBX7.08+Firebird 1.5
básicamente tengo algunas dudas con respecto al diseño de la misma y tal vez alguno ya se cruzó con problemas similares..
la misma es multiusuario de dos capas y estoy tratando de implementar todas las 'bussines rules' en el server.. pero hay un par de temas que no se para donde arrancar..

por ejemplo un caso de los que les comento (simplificado): EJERCICIOS[ID_EJER, FECHA_INIC, FECHA_FIN] y ASIENTOS[ID_ASIENTO, ID_EJER, FECHA, IMPORTE] bueno aca hay una obvio relación de integridad y la relación es uno a varios.. el tema es que la fecha del asiento tiene que caer entre FECHA_INIC y FECHA_FIN del ejercicio que esta cargado.. hay dos formas de realizar esto segun el firebird book: en un CHECK a nivel de tabla y con TRIGGERS.. por lo visto el CHECK dice que no hay que hacer referencias a otras tablas solo a la fila actual, asi que descartado.. cuando leo la documentación de los triggers dice que no es recomendable que se verifiquen en ellos relaciones de integridad por el tema de las transacciones..

supongamos que codifico los BEFORE_INSERT y BEFORE_UPDATE para ASIENTOS y el BEFORE_UPDATE para EJERCICIOS chequeando los rangos de fecha (para q todo siempre caiga en el rango, sino cancelo), que pasa si estoy cargando un asiento y otro usuario desde otra pc me esta modificacando la fecha de inicio del ejercicio donde estoy cargando y me lo hace invalido..? hay alguna secuencia de operaciones que podria dejar la BD sin cumplir las reglas del negocio?
estuve pensando que todos los problemas vienen por usar SNAPSHOT en la transacción.. si para la edición de datos uso siempre READ COMMITED se soluciona todo? y porque el consejo de HELEN en el Firebird Book entonces?

tengo 500 temitas de estos en la BD, suponiendo que no sea tan importante el uso concurrente DEL MISMO EJERCICIO (para seguir con el ejemplo..) o otra cosa en cuestion, no sería mas sencillo implementar un propio esquema de de LOCKING donde se agrega a la tabla EJERCICIO un campo para indicar que este en uso (asi la lógica del programa lo tiene en cuenta y no intenta nada que puede complicar..) se que los expertos desanconsejan estas cosas, pero el tema de las transacciones me esta complicando el diseño y quiero simplificar un poco las cosas (estando dispuesto a pagar el precio en la usabilidad del programa q en este caso no se justifica lo q pierdo)

cualquier comentario o consejo es agradecido..