12 respuestas en este tema

[cram]

Buen día gente.
Tengo un problema existencial, espero que puedan darme su opinión, ya que si bien tengo encaminada la solución no estoy muy seguro que sea la mejor.
El tema es acerca de la arquitectura de una base de datos que pueda operar off-line pero que mantenga conexión con un centro cada tanto.
Se trata de un comercio con varias sucursales donde la lista de archivos puede ser centralizada o propia de cada sucursal. Si elijo la independencia de la lista de artículos, también elijo la incapacidad de centralizar la información para totalizar algunos valores ya que en algún momento las sucursales tendrán codificado de manera difernte un mismo artículo concreto (aclaro que uso la palabra artículo, dado que European Article Number lo usa y es en ese sentido de la traducción).
Por otra parte tengo el concepto de la lista central o maestra que se distribuye a las sucursales, pero que éstas no pueden modificar, sino solo usar. El gran problema ocurre, en este segundo caso, cuando se intenta comprar un artículo que no existe. La dependencia de los datos con la casa central se hace notoria, ya que la sucursal deberá esperar que se distribuya una actualización del archicvo maestro para poder registrar la compra de los mismos.
Existen varias soluciones , algunas triviales, otras no, pero al final todas ellas salen del problema de trabajar off-line, ya que de ser on-line, el problema no existiría.
Si alguien me preguntara por qué off-line (y me quisiera enterrar con los dinosaurios) les digo que es común en mi región la frase "no hay sistema" por referirse a que cayó la conexión con internet y no se pueden realizar transacciones como cobros, pagos, depósitos, etc. en bancos, etc. 
Espero que alguien haya comprendido mi problema y pueda darme una mano.
Muchas gracias, saludos 

La mejor solución a la que llegué es operar on-line para la compra y la actualización de los datos y off-line el resto del tiempo, pero incluso esa porción de tiempo en línea quisieroa quitar, haciendo posible todo en diferido.

Este asunto tiene mucho que ver con la integridad referencial (pero de antemano) 

[genriquez]

Hola Cram

No sé si te entendí bien, pero trabajando con DataSnap, puedes trabajar conectado cuando haya oportunidad y en caso de perderse la conexión, cambiarias a un servidor local o a archivos locales sin problema y solucionas las dos situaciones de una sola vez.

En cuanto a la base de datos se diseña como si fuera una sola en una red LAN, pero el manejo se le da en la conexión.

Si es por este lado (si entendí bien) me avisas y trabajamos en una solución sobre ese estilo.

Saludos.

[Wilson]

Al igual que Gustavo pienso que con Datasnap tu problema es fácilmente abordable. Cuando me he encontrado con problemas similares en donde la conexión a internet es muy inestable, a groso modo, lo que he hecho es tomar el toro por los cuernos desde el diseño de la DB principal, en Colombia la dirección de impuestos permite un consecutivo diferente para cada sucursal, por lo tanto las tablas que involucran números consecutivos simplemente las diseño con una clave primaria o una restricción de tipo unique compuesta por dos campos, uno con el ID de la sucursal y otro con el propio consecutivo que se generará de manera local para cada sucursal.

A las tablas susceptibles  de trabajar de manera desconectada simplemente les agrego un campo que permite nulos para almacenar la fecha y hora de sincronización, entonces cualquier movimiento lo guardo inicialmente en la DB local de la sucursal, un segundo procedimiento (en segundo plano) intenta "subirlo" a la DB principal, si lo logra entonces almacena la fecha y hora de sincronización de lo contrario esta sigue siendo nula, luego es muy fácil implementar de manera automática o manual un procedimiento que revise los registros que no tienen fecha y hora de sincronización y los suba.

Luego se puede disponer de servidores locales en cada sucursal que pueden ser accedidos desde un cliente en la oficina principal para auditar el estado de las DB locales.

Aunque los TClientDatasets utilizados en Datasnap son muy poderosos y permiten guardar su contenido en un archivo local y posteriormente aplicar los cambios en el servidor, cuando la conexión es muy inestable se hacen muy dispendiosas las tareas de sincronización, por ese motivo me decanto por una base de datos local. Aunque hay herramientas para hacer una replicación mucho más técnica, hasta ahora no tengo experiencia con ninguna.

Es solo una idea.

Saludos.

[cram]

Muchas gracias por responder, Genriquez y Wilson. Pero no es ese el caso. Quizá me expliqué mal.
Claro que con DataSnap se soluciona el problema de la conexión (cuando no existe y luego se reanuda).
El problema va más hacia el lado de lo que se llama "business rules". En mi caso tengo el gran problema de dar o no la posibilidad de crear elementos a una sucursal o no. Para el caso de una arquitectura cliente-servidor es fácil, solamente puedo permitir a cada sucursal crear esos elementos cuando esté conectada a la central (con una base de datos centralizada) y con DataSnap facilitaría los espacios en que no haya conexión. El mayor problema será como casi siempre los bloqueos (o solución de concurrencias).
Si por un lado permito a cada sucursal crear artículos propios al momento de la compra, estoy generando el gran problema de tener una lista de artículos por cada sucursal y un lío para central al tener que "mapear" esos artículos en artículos únicos para generar estadísticas, conocer existencias, etc.
Si por otro lado solo permito que casa central pueda crear los artículos y no a las sucursales, estoy limitando a estas últimas a estar ligadas a la sucursal al momento de registrar la compra y mantener una copia de la última lista de artículos generada (solo para aquellos casos en que los artículos a comprarse no existan), pero tengo el problema de tener una lista única (maestra) de artículos y el deber de actualizar en cada sucursal para poder realizar tanto compras como ventas. (A este asunto le llampe distribución de los datos o actualización).
Además hay que tener en cuenta que pueden existir sucursales con fábricas que se verían muy beneficiadas con la independencia de la creación de artículos por parte de la casa central. En fin, un dilema existencial para la política de la empresa.

Mi solución final (hasta ahora) es que las compras se registren en la casa central y los artículos nuevos se generen allí, creando la dependencia -antes mencionada- de las sucursales. El mayor problema será el registro de la entrada de los artículos y el envío de los documentos tras la compra por parte de la sucursal. Pero soluciono el caso de la integridad referencial (adelantada si se me permite) que existirá al intentar comprar algo que no existe. Por otra parte solucionaría el problema del ingreso de artículos haciendo que tras la compra la casa central genere una entrada en una especie de "limbo" antes de moverla a una sucursal en cuestión (destino final de la compra). Otro problema ligado a la dependencia es que no se podrá vender un artículo hasta que central no envíe la modificación que hará ingreso al stock en la sucursal.

En la base de datos tengo separado precio y existencias de la lista de artículos y esto es un costo adicional al momento de decidir.
Por eso mi pregunta va más allá de el tema de offline/online (cosa que en un principio es el limitador) y no lo soluciono con tablas virtuales ni DataSnap.
Mi problema en este caso sería falta de experiencia en la solución o mejor dicho algo de "mercadismo básico".

Aun así les agradezco su tiempo  de nuevo. 

Saludos.

[Wilson]

Planteas un escenario en el cual pareciera que la empresa se va a quedar desconectada por periodos muy largos de tiempo, y eso hoy en día aun en el tercer mundo es bastante improbable.

El permitir que cada sucursal cree artículos a su antojo es ilógico e inconveniente por innumerables razones. En una aplicación que desarrollé recientemente, tenía que resolver algo muy parecido a tu caso, en el que las sucursales hacían su pedido diario con base en la rotación de los productos, la aplicación generaba el pedido pero el administrador de la sucursal podía ajustarlo, el pedido quedaba en estado "POR APROBAR" y la aplicación manda un mensaje a la oficina central en donde alguien autorizado revisa y reajusta el pedido, cuando el estado cambia a "APROBADO", la aplicación manda el pedido al proveedor, cuando no había internet este proceso simplemente se surtía vía fax.

Saludos.

[cram]

Wilson, aunque parezca mentira, me aclaras más los tantos con esta respuesta.
A veces estoy tan confundido que doy rienda suelta a soluciones de problemas extravagantes planteados por clientes que no tienen los pies sobre la tierra.

El permitir que cada sucursal cree artículos a su antojo es ilógico e inconveniente por innumerables razones. En una aplicación que desarrollé recientemente, tenía que resolver algo muy parecido a tu caso, en el que las sucursales hacían su pedido diario con base en la rotación de los productos, la aplicación generaba el pedido pero el administrador de la sucursal podía ajustarlo, el pedido quedaba en estado "POR APROBAR" y la aplicación manda un mensaje a la oficina central en donde alguien autorizado revisa y reajusta el pedido, cuando el estado cambia a "APROBADO", la aplicación manda el pedido al proveedor, cuando no había internet este proceso simplemente se surtía vía fax.

Es cierto, si bien tiene solución, genera una cantidad enorme de problemas. Por esa razón anteriormente -a otro cliente- le había sugerido que solo una sucursal (la principal o casa central) sea la que se encargue de las compras, pedidos, y eventualmente creación de los artículos que se requieran.
Aunque no lo solucionaré de la misma manera, dado que quedarían locos por los papeleos, pienso simplemente privar de ciertos privilegios a las sucursales que no sean la central y listo. No hay vueltas.
Como había comentado hasta el momento lo que pensaba hacer es una lista, y que la casa central se encargue de mantenerla, cuando se generen las compras (incluso en una sucursal cualquiera) se enviarán los papeles de la compra para que se registren en la casa central, esto le dará cierta independencia en las decisiones. A lo sumo generará un día de demora (el momento en que vuelva la información) en caso que se procese solo por la noche.

Saludos.

[genriquez]

Hola Cram.

Ese problema realmente es un tema administrativo como tu lo dices, se controla por medio de permisos.  en mi opinión la mejor manera es centralizarlo efectivamente, ya que la creación de artículos (ítems) sin control es un problema grave.

Es una buena práctica cuando hay tanta gente interviniendo en estos temas, que se creen solicitudes y alguien las aprueba, así queda el registro de todo lo que se hace (trazabilidad en Colombia).  Ej. las sucursales crean un registro donde solicitan la creación de un artículo,  luego alguien lo aprueba y le asigna el código de forma centralizada.

Igualmente debería crearse un registro de las solicitudes de pedidos,  estos datos serían aprobados por alguien (ya sea centralizado o de la misma sucursal) y al momento de aceptarlo, actualizaría la lista que mencionas.  (todo esto lo hago más por auditoría y control que por otra cosa).

Ya quien asuma el pedido y lo envié es cuestión de permisos, al igual que el resto de la aplicación y tu simplemente lo controlas de acuerdo a las políticas administrativas de la empresa.  la ventaja de hacerlo así que puedes adaptarte a diferentes tipos de empresas.

Saludos.

[giulichajari]

Yo estoy desarrollando como comento en otros temas una aplicacion con DataSnap, para 3 sucursales dentro de una misma ciudad, y tambien pense tener una LAN con el servidor y la bd (una replica) en cada sucursal por si se corta ineternet.
La ventaja es que en mi caso las 3 sucursales hacen solo la factura, y en la casa central esta el jefe. entonces puedo tener la lista de articulos con sus precios actualizada(cuando el jefe la actualiza, se actualizan las 3), y las lista de clientes tambien.

Pero, mientras hay internet la deuda de un cliente se actualiza en el momento de la compra, es decir la bd esta centralizada, solo se usa la distribuida en LAN cuando se corta internet.
Por que ademas para tener la bd distribuida debes recorrer todos los servers en busca de la info de cada sucursal: ej: armar el detalle de la factura a fin de mes, para los que tienen cuenta.

Yo solo creare un modulo que grabe los cambios de cuando no hubo internet en la bd central.

Osea el asunto cambia si ademas de tener vendedores en las sucursales tienes por ej: secretarios administrativos , osea depende de la estructura de la organizacion.

[Wilson]

Aunque no lo solucionaré de la misma manera, dado que quedarían locos por los papeleos.

En la solución que te comento no hay papeleos de ninguna clase, las solicitudes, los mensajes, aprobaciones (cambios de estado), alarmas, etc, todo se maneja sobre la mismísima aplicación con base en los permisos y queda rastro absolutamente de todo para las auditorías.

Un cordial saludo.

[cram]

Se me aclaran muchas dudas.
Lo más cerca que estuve de un sistema grande (por así llamarlo) fue donde trabajé hace mucho como operador (Libertad de Groupe Casino que también existe en Colombia). En él, los POS (Point Of Sale) dependían de la información suministrada por un servidor local (el de la sucursal) que les proveía la lista de artículos y las promociones (si las hubiera, éstas eran como scripts, supongo) y permanecían off-line, por la noche se les "extraía" la información de venta. En el caso de lo que denominaban islas, los puntos de venta tenían la capacidad de ver existencias. Pero en fin, todo se manejaba desde Casa Central. Lo que me arrepiento actualmente, es no haber ahondado mis conocimientos acerca de la solución de cómo realizaban las compras. Recuerdo que sus archivos de artículos eran bastante "sucios" (o sea lleno de información basura), pero el sistema funcionaba para lo que era necesario. Al margen, pero también recuerdo que usaban un motor de base de datos llamado Btrieve (un dinosaurio, creo que de Borland) para la información de las cajas y se comunicaban entre las sucursales para la minería de datos con BDE. Esto actualmente habrá cambiado (seguro).
Por aquí, la mayoría de los supermercados tienen centralizada la información, las mueblerías lo mismo. Pero al intentar dar más libertad de movimiento para proveer potencia de acción a las sucursales, algunas realizan sus propias compras y éste es mi "dolor de cabezas" ya que nunca tuve contacto con algo así.

El código, ese es el quid de la cuestión. Se necesita hacer referencia a qué se compra.
Creo que esta es la solución:

Es una buena práctica cuando hay tanta gente interviniendo en estos temas, que se creen solicitudes y alguien las aprueba, así queda el registro de todo lo que se hace (trazabilidad en Colombia).  Ej. las sucursales crean un registro donde solicitan la creación de un artículo,  luego alguien lo aprueba y le asigna el código de forma centralizada.

Y mi problema se reducirá a acostumbrar a sus operadores a utilizar bien el sistema.

Uno de mis grandes problemas es que quiero dar soluciones rápidas y el tiempo de espera que puede tener el sistema al aprobar un código puede ser la desesperación de algún operador. Pero, el otro lado es peor.

A las tablas susceptibles  de trabajar de manera desconectada simplemente les agrego un campo que permite nulos para almacenar la fecha y hora de sincronización, entonces cualquier movimiento lo guardo inicialmente en la DB local de la sucursal, un segundo procedimiento (en segundo plano) intenta "subirlo" a la DB principal, si lo logra entonces almacena la fecha y hora de sincronización de lo contrario esta sigue siendo nula, luego es muy fácil implementar de manera automática o manual un procedimiento que revise los registros que no tienen fecha y hora de sincronización y los suba.

Luego se puede disponer de servidores locales en cada sucursal que pueden ser accedidos desde un cliente en la oficina principal para auditar el estado de las DB locales.

Ese tema de los nulos y la auditoría de Wilson parece interesante, pero no debo tener la cabeza como la tengo ahora para implementarlo.

Una vez muchas gracias, creo que puedo dar como solucionado el tema.

Saludos

[Sergio]

El problema principal es poder dar de alta articulos en una sucursal sin tener conexion con la BD maestra de la central, aunque es mejor que la central lo haga y lo autorize, de alguna forma tienes que dar ese alta para luego enviarselo (no vas a usar papel y fax digo yo), se puede solucionar así:

Cuando la sucursal 03 necesita dar de alta un articulo nuevo sin tener conexión se usa un código temporal, digamos "TMP.03.001" (codigo temporal 001 dado por la sucursal 03). Haces tu pedido (pendiente de aprobacion) y cuando hay conexion, se envia a la central.

Al conectar con la central, el programa de la sucursal mira a ver cuantos temporales tiene creados, y les asigna codigo final (de forma automatica, no se si el codigo tiene alguna informacion, pero si es asi, mala decision, codigo = no contiene informacion). Este cambio de codigo se hace tambien en la base de datos local (en firebird si has definido las relaciones bien al cambiar el codigo del articulo se modifican en cascada todas las referencias) y listo, queda el pedido guardado en la central e identico del que tienes en local.

[Wilson]

Aunque el amigo Cram ya dio por resuelto el tema, hay cosas interesantes por debatir.

El problema principal es poder dar de alta articulos en una sucursal sin tener conexion con la BD maestra de la central, aunque es mejor que la central lo haga y lo autorize, de alguna forma tienes que dar ese alta para luego enviarselo (no vas a usar papel y fax digo yo), se puede solucionar así:

En mi caso las sucursales no necesitaban dar de alta artículos, lo que si era obligatorio hacer diariamente era crear el pedido (dado que la directiva era pedir lo que se vendió en el día, excepto que fuera un producto de muy baja rotación) y este debía ser aprobado, cuando había línea no había ningún problema de lo contrario había que usar el fax si o si porque había una hora límite para hacer el pedido consolidado diario, luego en línea con un procedimiento muy sencillo se sincronizaban las tablas involucradas. 

Cuando la sucursal 03 necesita dar de alta un articulo nuevo sin tener conexión se usa un código temporal, digamos "TMP.03.001" (codigo temporal 001 dado por la sucursal 03). Haces tu pedido (pendiente de aprobacion) y cuando hay conexion, se envia a la central.

Al conectar con la central, el programa de la sucursal mira a ver cuantos temporales tiene creados, y les asigna codigo final (de forma automatica, no se si el codigo tiene alguna informacion, pero si es asi, mala decision, codigo = no contiene informacion). Este cambio de codigo se hace tambien en la base de datos local (en firebird si has definido las relaciones bien al cambiar el codigo del articulo se modifican en cascada todas las referencias) y listo, queda el pedido guardado en la central e identico del que tienes en local.

Es una muy buena solución, el único inconveniente que le veo a este modelo es en el hipotético caso (todo es probable), que dos sucursales den de alta el mismo artículo con alguna sutil diferencia en el nombre o descripción, que hagan que la aplicación los tome como diferentes, aunque esto podría ser resuelto con la intervención humana en un proceso de consolidación del los artículos con código temporal a realizar en la oficina central.

Un cordial saludo.

[cram]

Pues no (no lo marqué como resuelto), solo dije que para mí está resuelto. Pero sigamos que es interesante vuestros puntos de vista (a mi al menos me sirvió un montón).
Precisamente lo que dice Sergio es lo que se me ocurrió al plantearme el problema, pero como bien dice Wilson, requiere intervención humana para el caso de ciertas descripciones (yo les llamo denominación) que pueden ser diferentes aun cuando se trate del mismo artículo (o producto).
En mi primera solución, agregaba un prefijo de sucursal al código y luego al enviar a Central, ellos se encargaban de la consolidación (yo le llamé desambiguación). Claro que en este caso jugaba un papel importante las clasificaciones en ciertos grupos que ayudan mucho a la desambiguación.
En mi segunda solución, creaba una lista de artículos para cada sucursal, haciendo que la central tenga una lista de todos estos artículos con una codificación única y diferente, pues ya le había otorgado independencia plena a las sucursales. Una tabla relacionaba los artículos de la sucursal con los artículos de central con una relación uno a muchos o ninguno.
Así, cuando las sucursales se referían libremente a sus artículos, central sabría de cual se trataba en particular con la tabla de relación y podría totalizarlos "felizmente". Esta segunda solución me gustó más por la independencia que daba a las sucursales.

El asunto es que además de esto, se tiene que evaluar no solo el sistema informático, sino el sistema de la empresa. Por esta razón, prefiero no usar mecanismos que puedan complicar o aten a una persona extra a la resolución de conflictos.
Por si fuera poco, yo separo, como dije antes, al stock en una tabla diferente que puede ser relacionada al ingreso y egreso de existencias. Que permite a su vez relacionar compars y ventas con el stock y en definitiva, relacionar una venta hasta la entrada misma del artículo, sea compra o compra interna. Por esta misma razón las tablas que utilizan el código temporal, deberán ser luego actualizadas con el código final y esto me da mala espina.

Por eso, a veces es preferible acorralar a las soluciones como vaquitas en vez de dejarlas libres y darles de pastar en un lugar determinado y seguro. Por eso me fui por el lado de la solución más simple: no dejar crear artículos a las sucursales, que las sucursales dependan de los artículos creados con buenas reglas en central y que las sucursales registren sus propias compras (pero con artículos únicos de la empresa).

Saludos.