Problemas para diseñar!
Buenas Experto! Acudo a ud. Por que mi experiencia en trabajar con bases de datos tipo MySQL es nula! Vamos al problema tengo un sistema cuya bases están en .DBF y quiero ponerlo en un MySQL la migración de datos y elaboración de las pantallas no son el problema el problema es la lógica del programa!! Con dbfs locales no hay problemas las re entiendo pero ahora que tengo un server central remoto!! Medio como que me pierdo!!
y surgieron los primero problemas si una de las sucursales remotas se queda sin internet no se puede trabajar! Así que, no me sirve!
decidí poner un server por cada sucursal y que la info de los server se mezclen en la servidor central ni bien tengan conexión! Pero hay me di cuenta que la estructura de las tablas da mucho lugar a errores, EJ que en 2 sucursales desconectadas se de alta a distintos proveedores con el mismo código, así también como productos o alta de un empleado nuevo y todos eso!!! Como podría gestionar esto no me hago una idea! Yo pensé en:
- Cuando no aya conexión con el server Central no se permita acceder a ciertas secciones del programa que generen este tipo de conflicto!
- Colocar dos Claves primarias la Clave Sucursal y la Clave Central!, en este caso como controlo las doble cargas??
y bueno me di cuenta que no tengo idea de como crear una base de datos que este diseñada para esto! Me podrías orientar con algún ejemplo de como tendría que ser una base de datos como la que pretendo! O como es la mejor lógica de replicación de información en distintos servidores!!
Desde ya muchas gracias!
1 Respuesta
Veo te volviste un kilo de estambre en eso.
Lo que planteas es un sistema cliente servidor semi-dedicado, con lo cual se te presenta lo siguiente:
1.- La dependencia de internet no es constante
2.- Los terminales no pertenecen a la misma LAN
3.- Los proveedores y clientes visitan distintas sucursales
A lo cual debes plantearte las soluciones:
1.- Debes crear una BD para cada LAN no para cada equipo de la LAN, es decir, cada red local cuenta con un servidor de datos capaz de almacenar todas las transacciones que se realicen en ella. Este servidor debe ser capaz de reenviar los datos a un servidor central cuando esté disponible, para lo cual necesitas que el servidor local no sea cliente, así podrás colocar un script que cada cierto tiempo chequee la conexión de red con el server central y emita los datos por rutina.
2.- Cuando los terminales(llámese los terminales de trabajo), no pertenecen a la misma LAN, debes, en primer punto, tener u server para cada LAN, como te mencioné anteriormente, pero además debes centralizar los datos, es decir, PROVEEDORES, solo se cargan en el servidor central y no en el servidor local, los CLIENTES solo se cargan en el servidor central, permitiendo trabajar con clientes genéricos en servidores locales. Esto para que una vez registrado el proveedor o el cliente puedas hacer una copia de estas tablas mediante código y guardes una copia en cada servidor local.
3.- Cuando los proveedores y clientes visitan varias sucursales o distintas LAN, por así clasificarlas, estas deben tener acceso a todos los datos, es decir, cada servidor de LAN debe poseer estos datos, que fue lo que comenté al final del numeral 2, se debe realizar una copia de cada tabla donde intervengan los proveedores y clientes, pero estas deben ser de solo lectura en los servidores locales y de lectura-escritura en el servidor central, así una vez se compruebe la conexión con el servidor central y no está disponible baja automáticamente al servidor local, pero no puede registrar solo consultar.
Este método que te mencioné fue implementado por Locatel (Locatel - Plenia) en toda su red de farmacias, pero a diferencia de una MySQL, ellos controlan todo por medio de IDOCS y Transacciones de MS SQL Server, para lo cual se pagan aproximadamente (aquí en venezuela) Bs 20.630,25; aproximadamente US$ 4.500,00.
Lo más factible y económico para implementar es con bases de datos MySQL y Script en PHP que te controlen el flujo.
Es un buen proyecto el que llevas, me gustaría ayudarte más, analiza estas indicaciones y me comentas...
XD si me he dado contra la pared en cuanto a esta lógica!! XD
y ahora que veo lo que me dices es como lo pensé pero no puedo poner en
practica ya que estoy muy mal acostumbrado a que cada terminal pueda
hacer todo sin otra restricción que los permisos de usuario! XD,
y no me cuadra lo de que se centralicen los datos como altas de
proveedores y Clientes!! pero por mera costumbre de que si en DBF se
puede
porque no en MySQL, pero leyendo encontré lo replicas esclavo - maestro
es solo cuestión de que configure mi sistema para que cuando quiera
hacer altas las haga en el servidor central y las consultas del server
local y cuando no se pueda conectar con server central no deje realizar
mas que consultas!! te agradezco por sacarme del bache mental en que me
metí!! XD y no te preocupes ni bien tenga otras dudas que te as
-- Solo me queda una duda con respecto a esto de esclavo - maestro se aplica a toda la base de datos o solo a tablas predefinidas por mi?
-- ya que como también este sistema manejara las ventas esas si son únicas por cada Sucursal y tengo que escribir en cada sucursal!! y mezclarlas en central (aquí usare el script que me dijiste!! XD)
Nuevamente muchas gracias!
Las ventas son únicas no solo por cada sucursal, sino por cada usuario e impresora (si utilizas las impresoras fiscalizadas), en todo caso deberías almacenarlas tanto local como remoto, dado que cada emisión de factura debe estar tanto offline como online.
Las ventas guardalas locales y luego las pasa al servidor central para que estén accesibles, pero recuerda que cada sucursal debe tener un código diferente y cada factura un código también diferente, ejemplo, si compré en la sucursal fulanita en la terminal 4 esta debería tener un código que sea 001 (el número de fulanita) seguida de 004 (numero de la terminal) quedando 001004 el cual es totalmente diferente del correlativo de la factura.
Le puedes adicionar a este código la fecha y la hora ejemplo
001004230320121033 y allí tienes un número único interno que te identifica a esa factura como perteneciente a la sucursal fulanita terminal 4 emitida el 23 de marzo de 2012 a las 10:33 am.
Con esto te salvas de enredarte la vida y llevas un mejor control...
