Bueno, a priori no
creo que exista una soluci�n �ptima para todos los casos. Ah� van algunos
criterios que se me ocurren:
- Revisar la
estructura de la base de datos. Si es correcta y se ajusta a las necesidades de
vuestro SW, interesa adoptarla. Caso contrario es probable que sea mejor crear
la vuestra propia e interfasear.
- Si la BBDD de la
aplicaci�n que incorpor�is est� sujeta a cambios de estructura que escapan a
vuestro control, no parece aconsejable que bas�is vuestra programaci�n en
ella.
- Uso de triggers e
integridad referencial: Si se quiere aplicar en la BBDD a incorporar se ha de
conocer bien la l�gica del aplicativo para no provocar errores, y si esta l�gica
puede cambiar en posteriores modificaciones de la aplicaci�n que no control�is,
los problemas pueden surgir m�s adelante.
De todas maneras,
supongo que la soluci�n �ptima pasar� por un punto intermedio: se adoptan las
tablas que convengan de la BBDD y se crean otras nuevas cuando se estime
oportuno. Para estas �ltimas yo recomiendo crearlas en una BBDD diferente e
intentar seguir una nomenclatura que las diferencie de las
otras
Saludos.
-----Mensaje original-----
De: Alfredo Reyes Moncayo [mailto:[EMAIL PROTECTED]
Enviado el: mi�rcoles, 04 de febrero de 2004 3:30
Para: Forum 400
Asunto: Ambientes de procesoHola a todos, quisiera leer sus opiniones y experiencias acerca de la conveniencia de dividir en diferentes bases de datos las diferentes compa��as en un software, o bien, manejar una sola.Me explico m�s a detalle, vamos a incorporarnos a un software corporativo y estamos en el an�lisis de:a) Generar nuestra propia base de datos.b) Incorporarnos a la base de datos ya existente pero como una entidad diferente.Me ser�a de gran ayuda sus experiencias y/o puntos de vista.Gracias de antemano.Jos� Alfredo Reyes Moncayo
Sistemas de Computaci�n Administrativa
Tel�fonos: Domicilio: (52) 5546 6228
Celular: (52) 04455 8553 9066
Email: [EMAIL PROTECTED]
Fernando P�rez.vcf
Description: Binary data
