Proyecto con DOS DCT

[Jaaljuba]

Hola a todos, durante mucho tiempo vi con malos ojos eso de temer que manejar dos DCT pero ahora estoy viendo la necesidad de revisar dicho tema teniendo en cuenta el siguiente escenario.

Tengo una aplicación en MsSQL y hasta aquí no hay problema, dicha aplicación es un sistema de gestión empresarial el cual lleva el control de compras, kardex, ventas, productos, etc, etc.
Ahora se decidió agregarle algo de BI y CRM pero para ello se requiere capturar otra información la cual es importante para obtener dichos resultados.
Aquí es cuando cristo empieza a padecer, al tener un solo DCT me estoy viendo obligado a cargar a los usuarios básicos con una cantidad de campos en la BD que no requieren y hasta a llenar campos que son obligatorios para los que quieren las características mas avanzadas. Obvio la base es exactamente la misma y su mantenimiento es continuo por lo que no quiero que se conviertan en proyectos separados pues nos obligaría a realizar los cambios a los procedimientos básicos DOS veces.

Algún tip o sugerencia al respecto.

[LeoPalomares]

Hola Javier,

Es un tema interesante el que estás enfrentando.
Antes de resolver si vas a trabajar con dos dcts tenés que analizar dos puntos:
1) Habrá necesidad de duplicar tablas entre ambos dcts?
2) Existirá algún app que deba acceder a tablas de ambos dcts?
en caso afirmativo, los accesos (a las tablas del dct que no es el propio) serán sólo por código o también es necesario implementar browses, forms, etc para esas tablas?

Por experiencia en módulos pequeños es simple responder estas preguntas y que esas respuestas sean válidas en el tiempo pero en módulos grandes la cosa se suele complicar porque estos rápidamente comienzan a tener vida propia y más pronto que tarde nos enfrentamos a situaciones en las que la respuesta a estas preguntas cambian.

Mi recomendación en estos casos es siempre la misma, un sólo dct y resolver los problemas de implementación en la instalación del producto.
La penalidad en este caso es tener una base de datos con una estructura más grande de la necesaria pero esto es más práctico que mantener dos dcts, y menos propenso a errores.

De todas maneras, si usás la técnica de dos dcts lo más probable que es que a la pregunta 1 respondas que no entonces te dejo un consejo, intentá no duplicar las tablas y, si no te queda otra entonces los campos que añadas a las tablas del dct original hacelo en una tabla extensión de la original.
Intentaré explicarme con un ejemplo:
El módulo principal tiene la tabla Clientes y para las nuevas funcionalidades necesitás en el nuevo dct la tabla clientes pero con 3 campos más entonces, lo que digo, es que estos tres campos no los añadas a la tabla clientes sino a una tabla ClientesEXT (extensión de clientes) que se relacione 1 a 1 con Clientes mediante la Primary Key de Clientes.
De este modo quien "controla" la tabla clientes es el módulo principal y no se ve afectada por lo que suceda en los nuevos módulos, si por necesidades del módulo principal tenés que agregar nuevos campos en la tabla Clientes entonces los agregás en la tabla Clientes de los dos dcts pero si por necesidades de los nuevos módulos tenés necesidad de agregar nuevos campos en la tabla clientes los agregás en ClientesEXT y sólo en el dct de los nuevos módulos.
Obviamente que en los nuevos módulos vas a tener que hacer siempre un join entre ambas tablas para acceder a los datos completos de cada cliente pero es un precio bajo a pagar por la flexibilidad que da esta solución y, además, como trabajás con sql tampoco debería preocuparte esto porque en realidad implementás un vista que resuelva el join entre ambas tablas y desde la aplicación (y desde el dct) siempre referenciás a la vista.

Espero que mis sugerencias te sean útiles.

[Jaaljuba]

Leo nuevamente mil gracias por tu ayuda y sugerencias, efectivamente creo que lo mejor va a ser seguir como vamos hasta el momento, es decir un solo DCT puesto que si así nada mas ya tenemos algunos problemas no me imagino con dos DCT.