Manejo de claves foraneas en sistemas transaccionales

[webness]

Hola a Todos. Mi panarama laboral actual se basa sobre una base de datos postgres, donde absolutmante el 100% de los datos son historicos y sufren actualizaciones 2 o 3 veces al año como maximo, donde la gran mayoria de las tablas poseen muchas columnas y muchos registros, por lo cual ninguna de estas tablas posee estrictamente clave foraneas:

Ej: Una tabla de lineas telefonicas, posee los campos de codigo_cidad,nombre_ciudad, codigo_barrio, nombre_barrio, para que al momento de consultar sobre esta no se hagan join sobre las respectivas tablas y mejorar el tiempo de conulta.

Mi pregunta puntual es: ¿Que tan recomendable es el uso de claves foraneas en sistemas altamente transaccionales, como lo podria un sistema de facturacion, una tienda OnLine, sistemas de asignacion de rutas y empleados para operaciones de instalacion y servicio tecnico?.

[huesos52]

¿Que tan recomendable es el uso de claves foraneas en sistemas altamente transaccionales, como lo podria un sistema de facturacion, una tienda OnLine, sistemas de asignacion de rutas y empleados para operaciones de instalacion y servicio tecnico?.

No es recomendable, es absolutamente necesario.
Las llaves foraneas nos aseguran la integridad de la información almacenada.
De no ser así, no se tendría la certeza de que la información de la base de datos sea consistente.

[webness]

Eso lo entiendo huesos, lo que me inquieta es lo siguiente: supongamos una tabla de clientes, la de productos, y las tablas de factura y detalle de esta, en un sistema donde se registran clientes a diario, y se hacen multiples ventas cuyo crecimiento es constante, supongamos al cabo de un año, y el intentar sacar un reporte sobre la cantidad de productos vendidos agrupados por mes y sucursal, hacer este query el cual podria requerir de un JOIN ENTRE UNAS 3 TABLAS, productos, facturas, detalle_facturas, no seria algo pesado???, de ser asi, que estrategias se recomiendan, aparte del uso de indices?

[huesos52]

Webness... Para determinar si el query es pesado o no, se tendrían que hacer pruebas.. pero creeme, que una solución para mejorar el rendimiento no es quitar la integridad referencial de las tablas.

Lo que puedes probar, es tener los constraints declarados como deferred not deferreable

DEFERRABLE
NOT DEFERRABLE
This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command. Checking of constraints that are deferrable can be postponed until the end of the transaction (using the SET CONSTRAINTS command). NOT DEFERRABLE is the default. Only foreign key constraints currently accept this clause. All other constraint types are not deferrable.

de: http://www.postgresql.org/docs/8.4/i...eatetable.html

Donde lo que se hace, es dentro de una transacción, evitar la consulta de constraints agilizando el proceso y al momento de hacer commit sobre la transacción se hacen todas las validaciones.

Te recomiendo mires a fondo el tema que puede ser una buena alternativa a tu problema.

saludos

[webness]

estuve investigando bastante, y los problemas de rendimiento y obtimizacion de consulta, es mas cuestion de diseño y politicas de manejo de datos historicos y actuales, es decir, no dejar que una tabla crezca y cresca, sino mantener en ellas solo datos actuales de una semana, un mes, y el resto pasarlas a tablas historicas, el resto, se puede usar mediante datawarehouse, pero alla no he llegado