Replicación
335 views
Skip to first unread message
Walter R. Ojeda Valiente
Dec 24, 2011, 5:01:31 PM12/24/11
to publice...@googlegroups.com
Continuando con este tema, hay varias formas de hacer replicación, cada una de ellas con sus respectivas ventajas y desventajas. En principio se puede utilizar un programa de terceros para llevarla a cabo o usar un programa propio que se encargue de esa tarea. Para quienes prefieran esta última opción, les comento aquí cual es mi estrategia, que la obtuve de un programa llamado CopyTiger, me gustó como funciona y le "repliqué" la idea.
:-)
1. Utilizo dos componentes:
a. El administrador
b. El replicador
2. El administrador se encarga de modificar la Base de Datos que será replicada. Para ello muestra en una grilla todas las tablas y todos los stored procedures y pregunta cuales se desea replicar y el nivel de prioridad y con esos datos crea los triggers correspondientes. Después de eso ya no se lo necesita, salvo que se desee replicar alguna otra tabla o algún otro stored procedure. Los triggers lo que hacen es grabar en un archivo de log el nombre de la tabla y la clave primaria de esa tabla. No se guarda la operación realizada (INSERT, DELETE, UPDATE) sino solamente el nombre de la tabla y la clave primaria. Por diseño todas mis claves primarias son generadas por el Firebird y autoincrementales (o sea que solamente sirven como identificadores de la fila y para nada más)
3. El replicador hace lo siguiente:
a. Pregunta cual es la Base de Datos origen
b. Pregunta cual es la Base de Datos destino
c. Pregunta si se hará una replicación bidireccional
d. Lee el archivo de log de la Base de Datos origen
e. Para cada fila de ese archivo de log:
. busca en la tabla especificada cual es la fila que corresponde a esa clave primaria y:
* si existe, guarda todos los datos de esa fila en la Base de Datos destino
* si no existe, pues .... nada
f. Si se eligió hacer una replicación bidireccional entonces la Base de Datos origen pasa a ser la de destino y viceversa. Se repite el proceso desde 3.d
4. Al finalizar la replicación el archivo de log es renombrado y se crea un nuevo archivo de log, totalmente vacío. Hago esto para no estar replicando los mismos datos una y otra vez. Además, como tengo el historial de todas las replicaciones realizadas si alguna vez es necesario rehacerlas sería muy fácil conseguirlo.
5. No importa si se cambió la estructura de alguna de las tablas, agregándole, modificándole o borrándole columnas, índices o triggers ya que los triggers que agregó el programa administrador se encargan de que las estructuras sean idénticas.
De esta manera tengo un 100% de seguridad que al finalizar el proceso de replicación ambas Bases de Datos contendrán exactamente los mismos valores en todas sus columnas (excepto las claves primarias, las cuales generalmente difieren)
Preguntar por la prioridad es necesario porque algunas filas deben necesariamente ser creadas antes que otras, supongamos que tenemos dos tablas: PRODUCTOS (que guarda el identificador, el nombre, la unidad de medida y otros datos de los productos) y MOVIMDET (que guarda el identificador del producto comprado o vendido, la cantidad, el precio, etc.). Si ambas tablas están relacionadas mediante una clave foránea según el identificador del producto entonces necesariamente primero se debe crear la fila del producto y luego la del movimiento porque si se lo quiere hacer al revés entonces el Firebird no lo permitirá ya que se quiere grabar en MOVIMDET un identificador de producto inexistente y por lo tanto será rechazado. Estableciendo que el número de prioridad de PRODUCTOS sea menor que el número de prioridad de MOVIMDET me aseguro que primero se replicará la tabla de PRODUCTOS y luego la de MOVIMDET.
Para saber siempre de donde proviene cada fila de cada tabla, todas las tablas tienen una columna llamada "Código de la Sucursal", la cual tiene el valor 0 si corresponde a la Casa Central, el valor 1 si corresponde a la Sucursal número 1 y así sucesivamente.
Podrán haber notado que una inserción y varias modificaciones de una fila en la Base de Datos origen solamente producen una inserción en la correspondiente tabla de la Base de Datos destino ya que se toma el valor actual de la fila que está siendo replicada, lo que le sucedió antes no interesa.
Adicionalmente, por si no quedó claro, cuando se instala la Base de Datos en la sucursal tiene exactamente la misma estructura que la Base de Datos en la Casa Central con las tablas maestras conteniendo datos y las tablas de movimiento totalmente vacías.
Saludos.
Walter.
:-)
1. Utilizo dos componentes:
a. El administrador
b. El replicador
2. El administrador se encarga de modificar la Base de Datos que será replicada. Para ello muestra en una grilla todas las tablas y todos los stored procedures y pregunta cuales se desea replicar y el nivel de prioridad y con esos datos crea los triggers correspondientes. Después de eso ya no se lo necesita, salvo que se desee replicar alguna otra tabla o algún otro stored procedure. Los triggers lo que hacen es grabar en un archivo de log el nombre de la tabla y la clave primaria de esa tabla. No se guarda la operación realizada (INSERT, DELETE, UPDATE) sino solamente el nombre de la tabla y la clave primaria. Por diseño todas mis claves primarias son generadas por el Firebird y autoincrementales (o sea que solamente sirven como identificadores de la fila y para nada más)
3. El replicador hace lo siguiente:
a. Pregunta cual es la Base de Datos origen
b. Pregunta cual es la Base de Datos destino
c. Pregunta si se hará una replicación bidireccional
d. Lee el archivo de log de la Base de Datos origen
e. Para cada fila de ese archivo de log:
. busca en la tabla especificada cual es la fila que corresponde a esa clave primaria y:
* si existe, guarda todos los datos de esa fila en la Base de Datos destino
* si no existe, pues .... nada
f. Si se eligió hacer una replicación bidireccional entonces la Base de Datos origen pasa a ser la de destino y viceversa. Se repite el proceso desde 3.d
4. Al finalizar la replicación el archivo de log es renombrado y se crea un nuevo archivo de log, totalmente vacío. Hago esto para no estar replicando los mismos datos una y otra vez. Además, como tengo el historial de todas las replicaciones realizadas si alguna vez es necesario rehacerlas sería muy fácil conseguirlo.
5. No importa si se cambió la estructura de alguna de las tablas, agregándole, modificándole o borrándole columnas, índices o triggers ya que los triggers que agregó el programa administrador se encargan de que las estructuras sean idénticas.
De esta manera tengo un 100% de seguridad que al finalizar el proceso de replicación ambas Bases de Datos contendrán exactamente los mismos valores en todas sus columnas (excepto las claves primarias, las cuales generalmente difieren)
Preguntar por la prioridad es necesario porque algunas filas deben necesariamente ser creadas antes que otras, supongamos que tenemos dos tablas: PRODUCTOS (que guarda el identificador, el nombre, la unidad de medida y otros datos de los productos) y MOVIMDET (que guarda el identificador del producto comprado o vendido, la cantidad, el precio, etc.). Si ambas tablas están relacionadas mediante una clave foránea según el identificador del producto entonces necesariamente primero se debe crear la fila del producto y luego la del movimiento porque si se lo quiere hacer al revés entonces el Firebird no lo permitirá ya que se quiere grabar en MOVIMDET un identificador de producto inexistente y por lo tanto será rechazado. Estableciendo que el número de prioridad de PRODUCTOS sea menor que el número de prioridad de MOVIMDET me aseguro que primero se replicará la tabla de PRODUCTOS y luego la de MOVIMDET.
Para saber siempre de donde proviene cada fila de cada tabla, todas las tablas tienen una columna llamada "Código de la Sucursal", la cual tiene el valor 0 si corresponde a la Casa Central, el valor 1 si corresponde a la Sucursal número 1 y así sucesivamente.
Podrán haber notado que una inserción y varias modificaciones de una fila en la Base de Datos origen solamente producen una inserción en la correspondiente tabla de la Base de Datos destino ya que se toma el valor actual de la fila que está siendo replicada, lo que le sucedió antes no interesa.
Adicionalmente, por si no quedó claro, cuando se instala la Base de Datos en la sucursal tiene exactamente la misma estructura que la Base de Datos en la Casa Central con las tablas maestras conteniendo datos y las tablas de movimiento totalmente vacías.
Saludos.
Walter.
Daniel Sánchez
Dec 25, 2011, 10:50:39 AM12/25/11
to publice...@googlegroups.com
Hola Walter
Saludos
--
Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047
Trujillo - Perú
--
Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047
Trujillo - Perú
Walter R. Ojeda Valiente
Dec 25, 2011, 5:28:38 PM12/25/11
to publice...@googlegroups.com
Hola Daniel
Yo trabajo así mismo, un ID de la tabla padre que se copia en la tabla hija para que teniendo el mismo ID sea fácil relacionarlas.
A medida que se realiza el proceso de replicación voy guardando en una tabla auxiliar el ID original (el de la tabla origen) y el ID que se generó en la tabla destino. Luego, cuando en otra tabla vuelvo a encontrar el ID original simplemente lo reemplazo por el ID generado por el replicador, de esa manera siempre coinciden el ID de la tabla padre con el ID de la tabla hija.
Para que ese algoritmo funcione, el número que indica la prioridad de la tabla padre debe ser menor que el número que indica la prioridad de la tabla hija, o sea que siempre se replica primero la tabla padre.
Saludos.
Walter.
Date: Sun, 25 Dec 2011 10:50:39 -0500
Subject: Re: [vfp] Replicación
From: resets...@gmail.com
To: publice...@googlegroups.com
Yo trabajo así mismo, un ID de la tabla padre que se copia en la tabla hija para que teniendo el mismo ID sea fácil relacionarlas.
A medida que se realiza el proceso de replicación voy guardando en una tabla auxiliar el ID original (el de la tabla origen) y el ID que se generó en la tabla destino. Luego, cuando en otra tabla vuelvo a encontrar el ID original simplemente lo reemplazo por el ID generado por el replicador, de esa manera siempre coinciden el ID de la tabla padre con el ID de la tabla hija.
Para que ese algoritmo funcione, el número que indica la prioridad de la tabla padre debe ser menor que el número que indica la prioridad de la tabla hija, o sea que siempre se replica primero la tabla padre.
Saludos.
Walter.
Date: Sun, 25 Dec 2011 10:50:39 -0500
Subject: Re: [vfp] Replicación
From: resets...@gmail.com
To: publice...@googlegroups.com
Daniel Sánchez
Dec 25, 2011, 10:54:42 PM12/25/11
to publice...@googlegroups.com
Con lo que entiendo de tu comentario es que realizas la replicación de manera manual, y no con ayuda del SGBD que manejas en tu caso Firebird.
Walter R. Ojeda Valiente
Dec 26, 2011, 1:24:19 AM12/26/11
to publice...@googlegroups.com
El Firebird no tiene incluido un replicador pero hay varios que pueden usarse, algunos gratuitos y algunos de pago. Yo preferí hacer mi propio replicador para poder tenerlo dentro de mis aplicaciones y así evitar la necesidad de decirle a los usuarios que usen un programa externo para realizar esa tarea.
Saludos.
Walter.
Date: Sun, 25 Dec 2011 22:54:42 -0500
Saludos.
Walter.
Date: Sun, 25 Dec 2011 22:54:42 -0500
Daniel Sánchez
Dec 26, 2011, 2:07:08 AM12/26/11
to publice...@googlegroups.com
Walter O. en mi caso uso SQL Server y trae incluido un replicador, pero no creo que considere el tema que te consulte al momento de replicar los datos de un servidor hacia otro.
Mas bien si alguien del grupo tiene experiencia en replicación usando SQL Server y maneja el concepto de tabla padre con tabla hijo relacionadas por el campo autoincremental de la tabla padre, como es que hace el replicador para mantener dicha relación, y este solo algo simple porque se podría tener relaciones mas complejas y lo que me parece que el replicador no consideraría este tema al momento de replicar y se perdería la relación ya que como la tabla padre maneja un campo autoincremental al realizar la replicación volvería a generar un nuevo número autoincremental en la tabla padre y al realizar esto perdería la relación con el número indicado en la tabla hijo.
Walter R. Ojeda Valiente
Dec 26, 2011, 2:38:17 AM12/26/11
to publice...@googlegroups.com
Hola Daniel
No sé como funcionan los campos autoincrementales en SQL Server, en Firebird es con un generador el cual se activa mediante un trigger al realizar la inserción. Yo grabo la clave primaria antigua y la nueva en una tabla auxiliar entonces cuando se replica la tabla hija reemplazo el identificador viejo por el nuevo. Sería algo como:
A procesar la tabla padre, en la tabla auxiliar:
- Guardar el nombre de la tabla
- Guardar la clave primaria antigua
- Guardar la clave primaria nueva (generada automáticamente por el Firebird cuando se insertó una nueva fila en la tabla destino)
Al procesar la tabla hija:
- Si está relacionada con otra tabla mediante una clave foránea:
. Buscar esa clave en la tabla auxiliar y hallar la clave primaria nueva que está grabada en la tabla auxiliar
. Reemplazar la clave foránea antigua por la clave foránea nueva
Mis claves primarias normalmente tienen dos columnas:
- Código de la Sucursal
- Identificador
En el caso de las tablas hijas, sus claves primarias tienen tres columnas:
- Código de la Sucursal (igual que el de su tabla padre)
- Identificador (igual que el de su tabla padre)
- Número de línea (que me indica su número de orden en la grilla en la cual se registró)
Recuerda que en el programa Admin se establecen las prioridades de las tablas, las tablas se van replicando según su orden de prioridad, de menor a mayor. Por ejemplo:
Tabla = MOVIMCAB (cabecera de movimientos), Prioridad = 100
Tabla = MOVIMDET (detalle de movimientos), Prioridad = 200
Por lo tanto, siempre se replicará primero MOVIMCAB y luego MOVIMDET
Y al finalizar la replicación ambas tablas continuarán correctamente relacionadas.
Hasta ahora nunca he necesitado que una clave primaria tenga más de 3 columnas, por eso mi replicador maneja hasta 3 columnas, si alguna vez llegara a necesitar más tendré que modificarlo.
Saludos.
Walter.
Date: Mon, 26 Dec 2011 02:07:08 -0500
No sé como funcionan los campos autoincrementales en SQL Server, en Firebird es con un generador el cual se activa mediante un trigger al realizar la inserción. Yo grabo la clave primaria antigua y la nueva en una tabla auxiliar entonces cuando se replica la tabla hija reemplazo el identificador viejo por el nuevo. Sería algo como:
A procesar la tabla padre, en la tabla auxiliar:
- Guardar el nombre de la tabla
- Guardar la clave primaria antigua
- Guardar la clave primaria nueva (generada automáticamente por el Firebird cuando se insertó una nueva fila en la tabla destino)
Al procesar la tabla hija:
- Si está relacionada con otra tabla mediante una clave foránea:
. Buscar esa clave en la tabla auxiliar y hallar la clave primaria nueva que está grabada en la tabla auxiliar
. Reemplazar la clave foránea antigua por la clave foránea nueva
Mis claves primarias normalmente tienen dos columnas:
- Código de la Sucursal
- Identificador
En el caso de las tablas hijas, sus claves primarias tienen tres columnas:
- Código de la Sucursal (igual que el de su tabla padre)
- Identificador (igual que el de su tabla padre)
- Número de línea (que me indica su número de orden en la grilla en la cual se registró)
Recuerda que en el programa Admin se establecen las prioridades de las tablas, las tablas se van replicando según su orden de prioridad, de menor a mayor. Por ejemplo:
Tabla = MOVIMCAB (cabecera de movimientos), Prioridad = 100
Tabla = MOVIMDET (detalle de movimientos), Prioridad = 200
Por lo tanto, siempre se replicará primero MOVIMCAB y luego MOVIMDET
Y al finalizar la replicación ambas tablas continuarán correctamente relacionadas.
Hasta ahora nunca he necesitado que una clave primaria tenga más de 3 columnas, por eso mi replicador maneja hasta 3 columnas, si alguna vez llegara a necesitar más tendré que modificarlo.
Saludos.
Walter.
Date: Mon, 26 Dec 2011 02:07:08 -0500
@Mlaynes
Dec 29, 2011, 10:08:19 PM12/29/11
to publice...@googlegroups.com
muy interesante aporte.. pero una de las principales ventajas por las que utilizo MySQL en mis desarrollos cliente-servidor en VFP es casualmente por su capacidad de efectuar de manera casi "simultanea" replicas de bases de datos completas (o de algunas de las tablas que querramos).. la fiabilidad, seguridad y rapidez del servicio es tan alta que incluso, en modelos cliente-servidor descentralizados, ademas de utilizarlos para copias de seguridad o respaldo, es posible utilizar las tablas "replicadas" para los procesos de consulta ó SELECTs, utilizando la base de dato "master" unicamente para efectuar sobre ella los INSERT, UPDATE y DELETTE de nuestro sistema, obteniendo una notable mejora de la velocidad y rendimiento de nuestros desarrollos o sistemas...
Ocurre que al conectarnos y trabajar mediante ODBC para poder acceder de forma remota a nuestra base de datos se consume mucho ancho de banda (promedio de 350 kbps hasta con picos de 500 o 600 dependiendo del tamaño de nuestras tablas), esto se puede mejorar usando ADO pero el promedio no baja de 250 kbps..), pero utilizando el servicio de replica mySQL el consumo de ancho de banda no pasa de 50 kbps.. no he encontrado en la documentación MySQL que protocolo utiliza cuando se pasa data entre sus servidores pero si es notablemente rápido y eficiente,. a consideración de lo expuesto, es que algunos de nuestros desarrollos los hemos adaptado a esa modalidad de trabajo y funcionan sin problemas..y a una velocidad que hacen parecer a nuestras aplicaciones descentralizadas "pesadas" como si fueran locales...
pueden revisar respecto a como configurar a MySQL para hacer replicaciones en :
- http://p0l0.binware.org/index.php/2007/04/18/mysql-replication/
- http://www.linuxtotal.com.mx/index.php?cont=info_admon_019
- y en la documentacion de MySQL: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html
y por supuesto, también pueden configurarse para replicación las bases de datos MySQL instalados sobre Windows (la mayoría de ejemplos los presentan sobre Linux)
saludos
@Mlaynes
Arnaldo Toledano
Dec 30, 2011, 7:29:33 AM12/30/11
to publice...@googlegroups.com
Muy interesante.
Hace mucho que quiero ver esto.
Ahora bien, tengo varias dudas, mas que dudas son ignorancias.
Si No utilizas ODBC
Si No utilizas ADO.
Desde el punto de vista cliente.
1.- Te conectas al servidor principal.
Como haces la conexión ?
2.- Para conectarte al "esclavo", como lo haces ?
Para el caso de consultas o modificaciones de las tablas supongo que tendrás dos conexiones y utilizas una u otra dependiendo que necesitas ?
Si me podes dar data de como conectarme te agradecería.
Hace mucho que quiero ver esto.
Ahora bien, tengo varias dudas, mas que dudas son ignorancias.
Si No utilizas ODBC
Si No utilizas ADO.
Desde el punto de vista cliente.
1.- Te conectas al servidor principal.
Como haces la conexión ?
2.- Para conectarte al "esclavo", como lo haces ?
Para el caso de consultas o modificaciones de las tablas supongo que tendrás dos conexiones y utilizas una u otra dependiendo que necesitas ?
Si me podes dar data de como conectarme te agradecería.
--
Arnaldo Toledano Tesys Informática Córdoba Argentina
Arnaldo Toledano Tesys Informática Córdoba Argentina
@Mlaynes
Dec 31, 2011, 1:21:42 PM12/31/11
to publice...@googlegroups.com
hola tesys:
vale la aclaración... Si utilizo ODBC ó ADO para conectarme a las bases de datos (MySQL, Postgress, Oracle, SQLServer, etc), solo que cuando voy a hacer los SELECT se conecto a la base de datos local "replicada" (que justo son lo que consumen mayor recurso de ancho de banda).. y cuando voy a hacer los INSERT, UPDATE ó DELETE me conecto a la base de datos remota "master" (aunque el caso "delete" casi nunca lo utilizo en mis desarrollos, prefiero crear un campo "estado" numérico de control) ..es cuestión de adecuar nuestra lógica de programación.. y funciona bien..
Aquí hay una discusión sobre el tema planteado como una alternativa a la replicación bidireccional, que también es posible utilizando MySQL Cluster, pero ese es un servicio más sofisticado, escalable y de paga :
saludos ..y por supuesto ...para todos: Feliz 2012 !!
@Mlaynes
Guillermo Gimenez
Apr 11, 2012, 10:41:14 PM4/11/12
to publice...@googlegroups.com
Estimado futuro EXsoltero, tengo una copia de este hilo (replicación), y me ha sido sumamente util, solo que me queda una duda, el proceso de replicación (claramente explicado) requiere tener las dos (o mas) bases de datos a replicar completas (todos las tablas, procedimientos, datos, etc etc). Mi pregunta es ¿como hacemos cuando la base de datos sea "exageradamente" grande? (ejemplo 2 o 3 Gb - totalmente viable hoy en día) y la transferencia sea vía internet (por Dial-up pa´complicar)... ¿¿será que tenemos una forma de replicar (actualizar, transferir, etc) solo los datos desde la ultima replicación que se realizó??... ojala que si... y lo importante es: ¿cómo lo hariamos?... tengo una vaga imaginación de como podría ser... pero no me animo a comentarlo... puede ser una super burrada!!!.. espero comentarios... gracias
|
Walter R. Ojeda Valiente
Apr 11, 2012, 11:01:41 PM4/11/12
to publice...@googlegroups.com
Hola Guillermo
Lo normal es que la replicación se haga SOLAMENTE de los datos que han cambiado, los que son distintos entre una Base de Datos y la otra.
Supongo que uno se podría imaginar, idear, (cranear diríamos en Paraguay) hacerlo con varios algoritmos diferentes, lo importante es que sea cual sea dicho algoritmo no estés duplicando datos ni dejando de copiar los que deben ser copiados.
Si una empresa tiene varias sucursales, cada sucursal debería tener solamente lo que le compete a ella y la Casa Central sí debería tener los datos completos.
¿Dial-up ahora, en una empresa? Eso ya no existe, si no puede pagar banda ancha, entonces que se olvide de tener replicación por Internet.
Saludos.
Walter.
Date: Wed, 11 Apr 2012 19:41:14 -0700
From: guille...@yahoo.com.ar
Subject: RE: [vfp] Replicación
To: publice...@googlegroups.com
Lo normal es que la replicación se haga SOLAMENTE de los datos que han cambiado, los que son distintos entre una Base de Datos y la otra.
Supongo que uno se podría imaginar, idear, (cranear diríamos en Paraguay) hacerlo con varios algoritmos diferentes, lo importante es que sea cual sea dicho algoritmo no estés duplicando datos ni dejando de copiar los que deben ser copiados.
Si una empresa tiene varias sucursales, cada sucursal debería tener solamente lo que le compete a ella y la Casa Central sí debería tener los datos completos.
¿Dial-up ahora, en una empresa? Eso ya no existe, si no puede pagar banda ancha, entonces que se olvide de tener replicación por Internet.
Saludos.
Walter.
Date: Wed, 11 Apr 2012 19:41:14 -0700
From: guille...@yahoo.com.ar
Subject: RE: [vfp] Replicación
To: publice...@googlegroups.com
Guillermo Gimenez
Apr 11, 2012, 11:08:49 PM4/11/12
to publice...@googlegroups.com
Buenas noches, gracias por la pronta respuesta, daba el ejemplo del dial-up, porque en estos días intente (sin exito) convencer aun cliente que todas las sucursales de su empresa tenga internet para facilitar la transferencia de informacion (replicacion) y me dijo: "tenemos linea baja en todas las sucursales, podemos conectarnos con el modem de la computadora, como se hacia antes", ataje todo lo que pude la risa y me fui pal baño!, entonces quizas sea una realidad lo del dial-up, no por no poder pagar sino por no querer!!...
Ahora me interesó lo de que cada sucursal tenga lo que le compete específicamente, es decir no tener los movimientos de las otras sucursales (segun yo entiendo), pero como puedo tener en "mi" sucursal el stock de un producto determinado en "tu" sucursal, como se puede manejar esa parte, que las sucursales no tengan todos los datos de movimientos, pero si el stock (mas o menos actual) de todas las sucursales...
Otra vez, gracias, me es super util comprender este proceso... Guillermo
|
Walter R. Ojeda Valiente
Apr 11, 2012, 11:29:28 PM4/11/12
to publice...@googlegroups.com
Hola Guillermo
Para que cada Sucursal tenga solamente los datos que le competen a ella, entonces en TODAS las tablas, sin excepción, debes tener una columna llamada CódigoSucursal.
0 = CasaCentral
1 = Fernando de la Mora
2 = San Lorenzo
etc.
Si la conexión de Internet es buena entonces lo más recomendable sería que todas las Sucursales se conectaran con la Base de Datos de la Casa Central y una o dos veces al día (quizás al empezar la jornada laboral y al finalizarla, replicar los datos que les competen) ¿Por qué esto? Para poder seguir usando las compus para registrar los movimientos si se muere Internet o si la Casa Central tiene algún problema.
De esta manera sería muy fácil saber desde cualquier Sucursal lo que hay en cualquier otra Sucursal, aunque eso no es lo recomendable, pero para casos particulares como tu ejemplo de la tabla de Productos se podría implementar muy fácil.
Cuando haces una consulta normal en cada SELECT incluyes el Código de la Sucursal, algo como:
SELECT CLI_CODIGO, CLI_NOMBRE FROM CLIENTES WHERE CLI_CODSUC = 2
Se supone que esa consulta se realizó desde una computadora de la Sucursal número 2. Solamente en la Casa Central deberían tener (normalmente) la posibilidad de consultar los datos de cualquier Sucursal.
Saludos.
Walter.
Date: Wed, 11 Apr 2012 20:08:49 -0700
Para que cada Sucursal tenga solamente los datos que le competen a ella, entonces en TODAS las tablas, sin excepción, debes tener una columna llamada CódigoSucursal.
0 = CasaCentral
1 = Fernando de la Mora
2 = San Lorenzo
etc.
Si la conexión de Internet es buena entonces lo más recomendable sería que todas las Sucursales se conectaran con la Base de Datos de la Casa Central y una o dos veces al día (quizás al empezar la jornada laboral y al finalizarla, replicar los datos que les competen) ¿Por qué esto? Para poder seguir usando las compus para registrar los movimientos si se muere Internet o si la Casa Central tiene algún problema.
De esta manera sería muy fácil saber desde cualquier Sucursal lo que hay en cualquier otra Sucursal, aunque eso no es lo recomendable, pero para casos particulares como tu ejemplo de la tabla de Productos se podría implementar muy fácil.
Cuando haces una consulta normal en cada SELECT incluyes el Código de la Sucursal, algo como:
SELECT CLI_CODIGO, CLI_NOMBRE FROM CLIENTES WHERE CLI_CODSUC = 2
Se supone que esa consulta se realizó desde una computadora de la Sucursal número 2. Solamente en la Casa Central deberían tener (normalmente) la posibilidad de consultar los datos de cualquier Sucursal.
Saludos.
Walter.
Date: Wed, 11 Apr 2012 20:08:49 -0700
Guillermo Gimenez
Apr 11, 2012, 11:38:29 PM4/11/12
to publice...@googlegroups.com
Mas claro agua (como decimos por aca), si bien estoy trabajando con dbc (dbf y cdx), he puesto una columna sucursal en cada tabla que hace referencia a la sucursal donde se creó el registro, teniendo ese dato puedo trabajar "tranquilamente" del modo explicado, otra vez gracias... |
Antonio Meza
Apr 12, 2012, 12:57:22 PM4/12/12
to publice...@googlegroups.com
Hola Maynes
Una pregunta, dices que utilizas Mysql en tus programas, como haces para la licencia de mysql que es de pago para cuando vendes el producto, no asi cuando el codigo es opensource? a diferencia de firebird que es gratis siempre.
saludos
Antonio Meza
@Mlaynes
Aug 8, 2012, 3:27:35 PM8/8/12
to publice...@googlegroups.com
bueno, desde abril del 2009 que Oracle anunció la compra de Sun Microsystems ahora la licencia MySQL es bastante específica :
Licencia
La licencia GNU GPL de MySQL obliga a que la distribución de cualquier producto derivado (aplicación) se haga bajo esa misma licencia. Si un desarrollador desea incorporar MySQL en su producto pero desea distribuirlo bajo otra licencia que no sea la GNU GPL, puede adquirir una licencia comercial de MySQL que le permite hacer justamente eso.
existe por supuesto también la opción que la licencia la adquiera el comprador del producto (y creo que es lo mas conveniente)
saludos
@Mlaynes
Guillermo MDQ
Aug 8, 2012, 6:44:45 PM8/8/12
to publice...@googlegroups.com
Bueno, eso es para el desarrolador que incorpora el MySQL en su producto o distribucion.
Pero que sucede si el MySQL lo instala el cliente y el desarrrollador solo instala el sistema solo, sin la base de datos ?
En ese caso entiendo que no se debe pagar licencia comercial.
Saludos
Guillermo
Pero que sucede si el MySQL lo instala el cliente y el desarrrollador solo instala el sistema solo, sin la base de datos ?
En ese caso entiendo que no se debe pagar licencia comercial.
Saludos
Guillermo
Miguel Angel Laynes Sanchez
Aug 8, 2012, 10:25:04 PM8/8/12
to publice...@googlegroups.com
claro.. pero sería muy bueno que quedara claramente estipulado en el contrato de desarrollo del proyecto.. siempre vale más prevenir...
--
@Mlaynes
saludos
@Mlaynes
--
@Mlaynes
Carlos Miguel FARIAS
Aug 9, 2012, 7:11:20 AM8/9/12
to publice...@googlegroups.com
Mysql era una buena opción hasta que cayo en manos de Oracle.
A partir de alli, en el tema licencia, hay que derivarse sobre postgresql o firebird.
Saludos: Miguel, La Pampa (RA)
A partir de alli, en el tema licencia, hay que derivarse sobre postgresql o firebird.
Saludos: Miguel, La Pampa (RA)
--
Reply all
Reply to author
Forward
0 new messages