Rgistro de datos multi-empresa

[integral]

Buen día amigos de la comunidad de VFP.

Estoy analizando el registro de datos para un sistema administrativo multi-empresa  y formularios hechos en VFP 9.0

Necesito consejos y puntos de vista con respecto a la forma del registro de datos del mismo.

En una misma base de datos registro todas las empresas que manejará el sistema

Creo una base de datos por cada empresa

Ademas creen ustedes que sea recomendable en estos casos utilizar una tabls DBC 

Agradezco sus comentarios y sugerencias.

Saludos,

INTEGRAL

[Luis la Romana]

En mi opinión el repositorio va a depender del uso que vaya a tener. Si crees que va a ser usado multiempresas por el mismo usuario o en la misma instalación (red) podría ser conveniente usar una sola tabla DBF o en SQL. Pero si va a usarse en lugares distintos la comunicación para tener todo junto se puede complicar.
Si usas la misma tabla DBF/SQL es necesario que pongas un campo para distinguir el número de empresa, si hay catálogos de cuentas o clientes igual debe estar un identificar de empresa. En eso hay que tener cuidado porque las empresas varían mucho, algunos usan código alfanuméricos en sus cuentas contables y otros no.
Finalmente debes tomar en cuenta que empresas de distintos grupos empresariales no pueden estar juntos por cuestión de Seguridad de datos y privacidad, respaldos, etc.

[mapner]

- Una sola BD multi-empresa: Orientada a Estudio Contables u Organizaciones con varias Razones Sociales. El usuario pueda cambiar de empresa fácilmente sin necesidad de re-ingresar. 

Requiere que todos los accesos a datos para consultas y/o actualizaciones (SQL) indiquen certeramente con que empresa está trabajando, o sea, un simple olvido en un Query puede mezclar información de diferentes empresas y emitir datos erróneos por lo que es más duro de mantener a nivel desarrollo. A su vez, está el tema de las tablas maestras: Clientes, Proveedores, Productos, etc... debes indicar por cada instancia si responden a una o varias empresas registradas. También está la configuración de permisos de seguridad Usuarios/Empresas = Que Usuarios pueden acceder a que Empresas. 

- Una BD separada para cada empresa: Es más fácil de mantener para el desarrollador en cuanto manejo y administración de datos salvo la inicialización de la nueva BD/Empresa y replicar los cambios en los metadatos o estructuras ante nuevos ajustes. Para el usuario significa salir y reingresar por cada cambio de empresa a operar. Más duro para emitir reportes consolidados de diferentes empresas. 

O sea, cada mundo tiene sus ventajas y desventajas.

pero debes tratar de no caer en el síndrome de la frazada corta (al intentar tapar la cabeza se destapan los pies)

Saludos

[Carlos Miguel FARIAS]

Coincido en general con lo planteado por Luis y Mapner.

Agrego que lo más importante a tener en cuenta es quien es el responsable de la integridad de la bd. Y quien es responsable ante los agentes fiscalizadores (afip, dgi, o como se llame en cada país).

En mi opinión, la mayor desventaja de un sistema multi-empresa es que tal como dijeron, tienes que evitar la filtración de datos de una empresa a la otra, tienes que evitar que si por ejemplo es un profesional contable y el órgano fiscalizador, le exige los datos de una empresa determinada por un control fiscal, simplemente, entregue la bd correspondiente y no tenga extraer (no se lo van a permitir) y pone "al descubierto" las transacciones de todas las empresas que están en el "multiempresas".

Otra desventaja es que si tienes que "quitar" una empresa, tienes que purgar la base y siempre puede quedar un residuo o quitar accidentalmente más de la cuenta.

Y por otra parte, ten en cuenta que un multiempresa, todas las consultas y procesos de datos tienen que tener el filtro por empresa, y si en un punto te lo olvidaste, la ley de Murphy indica que vas dar cuenta con el "you are fired"

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, un tal Vader entró a trabajar a la AFIP

[integral]

Gracias  por sus comentarios y sugerencias...

Ceen ustedes que sea recomendable para este caso utilizar una tabla DBC o es lo mismo trabajar con tablas nativas DBF...

Me podrian ayudar con un ejemplo de una tabla DBC

Saludos,

INTEGRAL

[Antonio Meza]

si vas a empezar un nuevo proyecto olvídate ya de los DBF, y cámbiate a un servidor de base de datos, en el futuro podrás usar cualquier lenguaje y migrar poco a poco.

En mi caso uso MariaDB, mi sistema es multi-empresa y tengo una base de datos por cada empresa, como mariadb al igual que mysql tienes la facilidad de que en el select indicas el nombre de la base de datos y listo, no tienes que cerrar el programa para cambiarte de empresa, solo cambio el nombre de la base de datos por parámetro y el usuario en cualquier formulario puede cambiar de empresa a la que tenga permisos.

saludos

Antonio Meza

[integral]

Bien Amigo Antonio Meza...

Tu planteamiento es bueno , podrias mostrar un ejemplo de lo que comentas con las Bases de  Datos

atte.,

INTEGRAL 

El lunes, 25 de abril de 2016, 21:57:47 (UTC-5), integral escribió:

[Antonio Meza]

No hay trucos simplemente en un select al servidor de MariaDB o Mysql pones así

Select * from NombreBaseDatos.nombreTabla

Tambien esta el comandos USE de mariadb que sirve para cambiarte de base de datos

Use NombreBaseDatos

Select * from NombreTabla

Pero son 2 instrucciones y de la primera forma solo necesitas enviar una.

saludos

Antonio Meza

[Marcelo Barberis]

Bueno yo opino q tengas una carpeta con tu bd y tablas base y cuando creas nueva empresa copiate todo el contenido de esa carpeta base a tu nueva empresa si es q vas a trabajar con dbf y en tabla aparte guardas los datos de las empresas q vas crando.
Ahora si usas mysql u otra bd sql yo te recomiendo solo una bd

[mapner]

Antonio,
Interesante el tema de indicar la bd en el select, la pregunta sería si puedes pasar el nombre de bd como parámetro en la instrucción sql o debes armarlo en VFP para luego enviarlo?
Una cosa sería
Sqlexec(ncon,'select * from facturas where empresa_id = ?m.emp_id','fac')

Y otra

Sqlexec(ncon,'select * from '+m.bd+'.facturas','fac')

[Antonio Meza]

En mi caso lo armo en el Select usando Text / Endtext para pasarlo por FoxyDb que usa al final SqlExec.

saludos

Antonio Meza

[Alfonso Ramirez Diaz]

Personalmente trabajo desde siempre todos mis sistemas como multiempresa y para eso ocupo una database diferente para cada empresa, ya sean tablas foxpro (cuando comence) o sql server o mysql.

Este ha mejorado el rendimiento por cada empresa y si a futuro crecen no hay problema, evita problemas de que se mezcle información, cada empresa tiene sus propios usuarios y permisos, ante cualquier desastre se puede recuperar por empresa, etc. tiene muchas ventajas y me ha servido muchisimo.

[Antonio Meza]

Esa es la mejor forma como comentas!!

En mi caso fui un poco mas allá y tengo una base de datos con catálogos fijos que cualquier empresa usa como usuarios, empresas  (sin datos ni domicilios) , bancos, impuestos, para poder asignar por usuario a que empresas pueden ingresar, y por cada empresa ya tiene su base de datos donde esta exclusivamente la información separada, una estructura algo así

* baseGlobal

     usuarios

     emrpesas

     etc

* empresa1

     facturación

     contabilidad

     etc

   empresa2

     facturación

     contabilidad

     etc

   empresa3

     facturación

     contabilidad

     etc

Esto me permite que un usuario ingrese al sistema y en todos los formularios le aparece una empresa predeterminada y si quiere cambiar solo seleciona la otra y no tiene ni siquiera que cerrar el formulario, puede por ejemplo ver una balanza, estado de resultado de diferentes empresas sin salir o cerrar dependiendo los permisos.

saludos

Antonio Meza

[Francisco ji]

Mi punto de vista.
 
En ocasiones, se requieren sistemas para una misma sociedad, pero para distintas empresas, vamos los mismos dueños tienen diferentes empresas del mismo giro y quieren tener un sistema igual en todas las tiendas o negocios, yo en esos casos me iría por una sola base de datos, distinguiendo la data por una columna "IdEmpresa", y aprovechar también los catalogos por ejemplo proveedores, artículos, grupos, etc. esto te permitirá estandarizar de alguna manera los catalogos.
 
Claro dependiendo de la aplicación, si vas a manejar empresas de diferentes dueños, ahí se va a ir complicando un poco mas, pienso como te comentan, que en algún momento mezcles información, sería muy malo para ti como desarrollador , pensar también en los respaldos, en la recuperación de la información, replicaciones , etc. , si fuese este caso yo optara por manejar base de datos por empresa.
 
Espero haber aportado algo, suerte.
 
 
 

---

Date: Tue, 26 Apr 2016 14:55:22 -0700
From: solv...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: Rgistro de datos multi-empresa

[integral]

Gracias nuevamente a todos los amigos por sus excelentes comentarios cada vez voy teniendo una idea mas clara sobre el tema en base a sus experiencias....

Para el amigo Antonio Meza 

Consulta : baseGlobal, empresa1, empresa2 son base datos DBC y ademas cada uno contiene tablas DBF

Los archivos DBC fueron creados por codigo 

atte.,

INTEGRAL

El lunes, 25 de abril de 2016, 21:57:47 (UTC-5), integral escribió:

[Antonio Meza]

Hola, uso MariaDB y la base de datos y tablas son creadas por codigo, primero las creo en HeidiSql y luego copio el codigo de Create que ahi mismo te muestra jejeje

saludos

[Carlos Miguel FARIAS]

Por si no lo conocian, recomiendo dbdesigner 4 o su fork.

Es grátis, permite diseñar las bd en forma gráfica, genera código para mysql, sqlite, postgress y unos cuantos más.

Interesante. El diseñador es muy flexible, pero lo más importante, te crea las FK automáticamente con solo apuntar tabla origen y destino.

Y si cambias el nombre en la tabla de origen, te actualiza el nombre en la destino.

Crea relaciones muchos a muchos (con tabla intermedia).

Permite documentar.

Y es GRATIS.

Para el amigo integral

Cuando usas tablas nativas. Estas pueden ser libres o incorporadas a una BD Fox.

En cualquiera de los casos, los datos de longitud fija (todos menos memo, blob) se almacenan en archivos .DBF. Los datos de longitud variable (los memo, blob) se almacenan en archivos .FPT. Los indices asociados a cada tabla se almacenan en archivos .IDX o .CDX. Los IDX son para no usar (se mantienen por compatibilidad descendente), si el .CDX tiene el mismo nombre que la tabla, sería uno estructural, que implica que se actualiza automaticamente cuando se cambian datos en la tabla asociada.

Las .DBC, contienen la metadata de la BD (tablas de sistema en otros SGBD).

Usar una DBC aporta la ventaja de nombres de campos más largos, integridad referencial y algunas otras ventajas.

En el modelo que te proponen, en cada carpeta, se colocan todas las tablas de una empresa y si usas BD Fox, las DBC/DBT correspondientes

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe

[integral]

amigo MIGUEL :

Te agradezco por tus comentarios. Me parece buena la idea de crear por codigo las tablas DBC  y agregarle tambien las DBF.

atte,

INTEGRAL

El lunes, 25 de abril de 2016, 21:57:47 (UTC-5), integral escribió: