Tenemos un escenario de tiempo de diseño de la base de datos de SQL Server ... tenemos que almacenar datos sobre diferentes organizaciones en nuestra base de datos (es decir, como Cliente, Proveedor, Distribuidor, ...). Todas las organizaciones de diferencias comparten el mismo tipo de información (casi) ... como detalles de dirección, etc ... Y serán referidas en otras tablas (es decir, vinculadas a través de OrgId y tenemos que buscar OrgName en muchos lugares diferentes)

Veo dos opciones:

Creamos una tabla para cada organización como OrgCustomer, OrgDistributor, OrgVendor, etc ... todas las tablas tendrán una estructura similar y algunas tablas tendrán campos especiales adicionales, como el cliente tiene un campo HomeAddress (que las otras tablas Org no tienen ) .. y viceversa.

Creamos una tabla de OrgMaster común y almacenamos TODAS las Orgs de diferencias en un solo lugar. La tabla tendrá un campo OrgType para distinguir entre los diferentes tipos de Orgs. Y los campos especiales se agregarán a la tabla de OrgMaster (solo los registros Org relevantes tendrán valores en dichos campos, en otros casos será NULL)

Algunos Pros y Contras de # 1:

PROS:

Ayuda a distribuir la carga mientras se accede al tipo de datos de la organización, por lo que creo que esto mejora el rendimiento.Proporciona un alcance completo para personalizar cualquier tabla de Organización particular sin afectar los otros tipos de Organización existentes.No estoy seguro de si los índices de diferencias en las tablas distribuidas / diferenciales funcionan mejor que una sola tabla grande.

CONTRAS:

Replicación del diseño. Si tengo que aumentar el tamaño del campo Código postal, debo hacerlo en TODAS las tablas.Replicación en la implementación de la manipulación (es decir, hemos utilizado procedimientos almacenados para las operaciones de CRUD, por lo que la replicación se multiplica por completo. 3-4 SP inerte, 2-3 SP SELECT, etc.)Todo se multiplica por la derecha, desde las restricciones de DB \ indexing hasta SP hasta los objetos de negocio en el código de la aplicación.El cambio (común) en un lugar también se debe hacer en todos los otros lugares.Algunos Pros y Contras de # 2:

PROS:

N-fold se convierte en 1-fold :-)El mantenimiento se hace fácil porque podemos intentar implementar puntos de entrada únicos para todas las operaciones (es decir, un solo SP para manejar las operaciones de CRUD, etc.)Tenemos que preocuparnos por mantener una sola mesa. La indexación y otras optimizaciones se limitan a una sola tabla.

CONTRAS:

¿Crea un cuello de botella? ¿Se puede administrar mediante la implementación de vistas y otra estrategia de acceso a datos optimizada?El otro lado de la implementación centralizada es que un solo cambio debe probarse y verificarse en TODOS los lugares. No es abstracto.El diseño puede parecer un poco menos 'organizado \ estructurado' esp. debido a esos pocos Orgs para los que necesitamos agregar campos 'especiales' (que son irrelevantes para las otras tablas)

También tuve en mente una Opción # 3: mantener las tablas Org separadas, pero crear una tabla OrgAddress común para almacenar los campos comunes. ¡Pero esto me pone en medio de # 1 y # 2 y está creando aún más confusión!

Para ser honesto, soy un programador experimentado pero no un DBA igualmente experimentado porque ese no es mi trabajo principal, así que, por favor, ayúdeme a obtener la compensación correcta entre parámetros como la complejidad del diseño y el rendimiento.

Gracias por adelantado. No dude en preguntar por cualquier consulta técnica y sugerencias son bienvenidas.

Hemant