Visual Basic Foro
General => General => Mensaje iniciado por: zxs23 en Diciembre 05, 2012, 11:40:00 pm
-
Antes que nada la BD sera de un hosting de internet(mysql), se trata de un proyecto mio a largo plazo y quisiera ir preparando algo, bueno este es uno de los puntos que estoy en duda.
Esta correcto esto que pienso, suponiendo que hay 2 tiendas en diferentes distritos en la misma ciudad y cada una tiene su numero serie en este caso 001(TiendaA) y 002(TiendaB).
Los N°facturas de ambas tiendas se deben guardar en una misma tabla o tambien podria utilizarse 2 bases de datos o en todo caso 2 tablas una para cada tienda. si se utiliza una sola tabla no se estaria recargando de informacion tomando en cuenta que habran factura,boletas,guias,etc de dos tiendas en una misma tabla o no tiene nada que ver esto si se tiene un buen motor de BD.
Tienda A-Factura-001-000150
Tienda B-Factura-002-000150
-
Primero que nada creo que el titulo del post es incorrecto, cuando lei tu titulo pensé que hablarías sobre Access, pero como hablas sobre MySQL lo mas correcto seria: "Puntos a tener en cuenta en un sistema Cliente/Servidor."
Los C/S ya son multiusuarios, pero los multiusuarios no necesariamente son C/S.
Yendo a tu tema, un poco difícil darte una respuesta viendo solo un arbol y no todo el bosque. Naturalmente no es viable que nos pintes el bosque asi que en mi caso tratare de soltar algo a ver a que le atino.
Si usas 2 BDs no le veo problema
Si usas 1 BD y 2 tablas tampoco le veo problema
Si usas 1 BD y 1 tabla (para este caso), tampoco le veo problema.
Todo radica en el diseño. Ciertamente cuando hagas consultas de consolidados le veo un poco mas de chamba a usar 2 o 3 BDs.
Fijate, en el ejemplo que pones, que uses 1 tabla en MySQL siempre que esté bien diseñadita y con los indices bien definidos la cosa ira bien (previo mantenimiento).
He visto en varios ERPs (que por definicion son sistemas grandes) que usan una sola BD, pero crean conjuntos de tablas por empresas. Por ejemplo:
Las tablas matrices (digamos que son 50):
Tabla1
Tabla2
... etc
Creo una empresa llamada EmpresaA y en la creación corres un script que te crea una copia de las 50 tablas pero con el prefijo de la empresa, llamándose entonces:
EmpresaA_Tabla1
EmpresaA_Tabla2
etc.
Entonces ya sabrías que hacer si creas la EmpresaB.
Pero luego comentas en tu post que para una factura en la tiendaA tienes la serie 001 y para la tiendaB tienes la serie 002, esto me invita a pensar que no es un sistema multiempresa sino un sistema multitienda, osea es la misma empresa con varias sucursales, igual podrías aplicar lo del ejemplo de las ERPs que te comento, pero yo en un escenario exactamente igual al que planteas preferí no dispararme la creación de esas 50 tablas del ejemplo anterior, sino use campos que distinguen las tiendas, ya van 2 años de esto y en marzo de 2013 seran 3 años y hasta la fecha la performance se mantiene mejor de lo esperado.
Osea, tengo 2 tablas para los documentos contables (factura y boletas de venta, las guia de remisión las llevo aparte), Estas tablas son CAB y DET.
En la tabla CAB entre otros campos tengo:
CAB_SUC_ID --> Id de la sucursal
CAB_DOC_ID --> Id del tipo de documento (2 factu, 3 BV)
CAB_DOC_SER --> Serie emitida
CAB_DOC_NUM --> Numero emitido
etc.
Y como dije, vamos bien. Recuerda que no basta que el motor sea bueno ya que la mayoria de motores en realidad son buenos, lo que interesa es tu diseño de la BD.
Saludos
-
Hola YACOSTA, como siempre das en el clavo, esa era la duda que tenia, gracias por compartir tu experiencia, bueno tengo otras dudas pero las dejo para mas adelante.
Ya que mencionaste a tu sistema multitienda has pensado en crearle tablas historicas o es muy pronto o mejor dicho en alguno de tus proyectos has realizado eso o no has tenido necesidad. Saludos
-
No, sinceramente no me tire una programación para gestionar los históricos y que el aplicativo aparte de acceder a las tablas "normales" también consulte a las tablas "históricas" (por decir algo) que eso seria lo interesante, lo que he visto es que pasado algunos años la BD completa la archivan dejándola solo como consulta y llevandose los saldos a una nueva BD (una nueva compañía realmente).
Fíjate que llegado el caso de que un cliente cumpla conmigo algunos años y ya vaya sintiendo lentitud en el sistema pues me tendrá que contratar para (si aun seguimos casados) hacerle el archivamiento de datos similar al ejemplo anterior que te di, osea que se archive pero que se pueda seguir usando para consultas históricas y esta no seria data de uso diario.
Lo que quiero decir es que no le veo necesidad de tirar programación para gestionar el tema de los históricos porque es un evento que ocurre una sola vez cada mucho tiempo (siendo un poco infidente Laive de aquí de nuestro pais corrió un proceso casi exactamente similar al que te comente arriba después de 10 años de operación!!!).
Las excepciones no se sistematizan, se da soporte.
Saludos
-
Asu despues de 10 años. Pues si tienes razon YACosta no creo que sea necesario programar los historicos, una pregunta mas, cual era la direccion de tu blog de firebird?
-
Saludos.
Bueno en mi firma esta la central de todos mis enlaces. En todo caso el enlace directo es www.vb6firebird.com
Gracias.