none
Es buena práctica tener una tabla contenedora de tablas? RRS feed

  • Pregunta

  • Hola a todos, solo una pequeña consulta... tengo un pequeño desacuerdo con el equipo de desarrollo en que ellos sugieren crear una tabla que contenga tablas dentro de si:

     

    CREATE TABLE [gene].[Contenedor](
    	[iIdContenedor] [int] NOT NULL,
    	[iIdTabla] [int] NOT NULL,
    	[iIdSubTabla] [int] NOT NULL,
    	[iIdContenedorPadre1] [int] NULL,
    	[iIdContenedorPadre2] [int] NULL,
    	[iIdMaeAcreedor] [int] NOT NULL,
    	[iOrden] [int] NOT NULL,
    	[nvCodigo] [nvarchar](20) NULL,
    	[iValorNumerico] [int] NULL,
    	[nvAbreviatura] [nvarchar](20) NULL,
    	[nvDenominacion] [nvarchar](200) NULL,
    	[nvDescripcion] [nvarchar](500) NULL,
    	[nvObservacion] [nvarchar](500) NULL,
    	[iIdRegUsuaRegistra] [int] NOT NULL,
    	[nvNombUsuario] [nvarchar](50) NULL,
    	[dtFechRegistra] [datetime] NULL,
    	[iCantidadModifica] [int] NULL,
    	[bEstado] [bit] NULL
    )
    

     


    esto para aquellas tablas maestras pequeñas que almacenan poca cantidad de registros.

    sin embargo hay un problema al establecer las relaciones primarias y foráneas ya que ésta solo puede ser iIdContenedor.

    Desde ya apelo a su experiencia de cómo es la forma como uds. manejan ese tipo de escenario, eso para aclarar ideas y ser mas conciso en mis propuestas, ya que yo preferiría separar en tablas individuales y no agruparlas.

    Desde ya agradezco su ayuda.


    Just me
    lunes, 23 de enero de 2012 22:06

Respuestas

  • Soy partidario de usar varias tablas pequeñas, ya que de esta manera es más fácil establecer las claves foráneas y realizar los JOINs entre tablas, que además quedan más legibles. El código quedará más limpio y claro, y será más sencillo de mantener. Al menos, esto se refiere al código SQL; es posible que el equipo de desarrollo pretenda recurrir a este truco para ahorrar subrutinas en la capa de acceso a datos en el lado cliente. En mi opinión, hoy en día ya no tiene sentido recurrir a este tipo de trucos, cuando existen multitud de herramientas de ORM (tales como Entity Framework) que automatizan la construcción de estas capas de código cliente.

    No hay problema en SQL Server para manejar múltiples tablas pequeñas. Las optimiza de forma que mientras son pequeñas les asigna una única página, permitiendo meter hasta 8 tablas pequeñas dentro de un único Extent, y sólo cuando crecen las expande ocupando Extents completos.

    lunes, 23 de enero de 2012 22:49
  • Jejeje, desviándome algo del tema. En vista a que se menciona el tema de ORM, hay una charla mostrando las desventajas del ORM y recomienda seguir con procedimientos almacenados. Lamentablemente la charla esta en inglés:

    http://www.idera.com/Events/RegisterWC.aspx?DoThis=TY&EventID=165

    Volviendo al tema, personalmente no le veo. Puede ayudar en el desarrollo, pero otra ventaja no tiene. Me parece mas dificil visualizar y hacer mantenimiento a la base de datos. 

    Yo creo que les va a dar dolores de cabeza a futuro. Mi idea es tener las tablas lo más simples y sencillas que sean posibles.


    MVP MCT MCTS Daniel Calbimonte

    http://elpaladintecnologico.blogspot.com
    martes, 24 de enero de 2012 0:24
  • Hola.

    Crea un debate si gustas. Pero preguntando en este foro, lo más a favor que obtendrás de este tipo de herramientas ORM es que, si se dominan y son bien explotadas, tienen un pase, ya que es un punto de vista muy parcial el que tenemos, (salvo excepciones como la de Alberto Población, que es justamente el que da ese límite de contrapunto al dominar ambos campos).

    A mí por ejemplo, no me gustan un pelo, ya que lo normal es que se usen mal (al menos cuando me he topado con ellas), y trasladan al desarrollador/administrador de base de datos (en este caso yo) todo ese ahorro de tiempo que gana el desarrollador de VB.Net (por citar uno).

    Sin embargo, preguntando lo mismo en un foro de desarrolladores puros, lo normal es encontrar justo el punto de vista opuesto. Si bien hay tema para debate, al estar casi todos en el mismo bando, quizá no sea muy enriquecedor.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    martes, 24 de enero de 2012 13:51
    Moderador

Todas las respuestas

  • Soy partidario de usar varias tablas pequeñas, ya que de esta manera es más fácil establecer las claves foráneas y realizar los JOINs entre tablas, que además quedan más legibles. El código quedará más limpio y claro, y será más sencillo de mantener. Al menos, esto se refiere al código SQL; es posible que el equipo de desarrollo pretenda recurrir a este truco para ahorrar subrutinas en la capa de acceso a datos en el lado cliente. En mi opinión, hoy en día ya no tiene sentido recurrir a este tipo de trucos, cuando existen multitud de herramientas de ORM (tales como Entity Framework) que automatizan la construcción de estas capas de código cliente.

    No hay problema en SQL Server para manejar múltiples tablas pequeñas. Las optimiza de forma que mientras son pequeñas les asigna una única página, permitiendo meter hasta 8 tablas pequeñas dentro de un único Extent, y sólo cuando crecen las expande ocupando Extents completos.

    lunes, 23 de enero de 2012 22:49
  • Jejeje, desviándome algo del tema. En vista a que se menciona el tema de ORM, hay una charla mostrando las desventajas del ORM y recomienda seguir con procedimientos almacenados. Lamentablemente la charla esta en inglés:

    http://www.idera.com/Events/RegisterWC.aspx?DoThis=TY&EventID=165

    Volviendo al tema, personalmente no le veo. Puede ayudar en el desarrollo, pero otra ventaja no tiene. Me parece mas dificil visualizar y hacer mantenimiento a la base de datos. 

    Yo creo que les va a dar dolores de cabeza a futuro. Mi idea es tener las tablas lo más simples y sencillas que sean posibles.


    MVP MCT MCTS Daniel Calbimonte

    http://elpaladintecnologico.blogspot.com
    martes, 24 de enero de 2012 0:24
  •  hay una charla mostrando las desventajas del ORM y recomienda seguir con procedimientos almacenados.

    Aunque no he visto la charla en cuestión, no estoy de acuerdo en que las dos cosas sean excluyentes. El ORM es el "mapeador objeto-relacional", que lo que hace es convertir los datos devueltos en forma "relacional" desde el servidor de base de datos en objetos para ser consumidos desde un programa escrito con un lenguaje orientado a objetos. Aunque se suele presumir que esos datos "relacionales" provienen de una consulta select enviada al servidor directamente desde el código generado por el ORM, no hay ningún motivo teórico por el que esos datos no puedan venir desde un procedimiento almacenado (o una función, o una vista). Por lo tanto, es legítimo que las consultas de datos se optimicen dentro de un procedimiento almacenado, y que los resultados se consuman desde programa por mediación de un ORM; no son dos tecnologías mutuamente excluyentes. Es más, en realidad casi todo el mundo lo hace así aunque no se den cuenta: En el lado servidor escriben un procedimiento almacenado, y en el lado cliente llaman al procedimiento y con un bucle recuperan los datos y los meten en un objeto dentro del programa. ¿Qué es eso de recuperarlos y guardarlos en un objeto? Efectivamente, es un mapeo objeto-relacional; básicamente se acaba de programar un ORM escrito a mano, aunque en ningún sitio intervenga explícitamente una herramienta clasificada como "ORM".

     

    martes, 24 de enero de 2012 6:43
  • Mi pequeño grano de arena: Segun mi experiencia los ORM suelen ser para problema en performance, aunque una gran mejora en los tiempos de desarrollo. Segun el tipo de emprendimiento deberás elegir que priorizar.
    Lic. Andrés M. Aiello | DBA MS SQL - Oracle | http://aiellodba.blogspot.com | @AndresAiello
    martes, 24 de enero de 2012 11:41
  • jajajaj, por favor moderador. Necesitamos crear otro tema aparte de ORM vs procedimientos almacenados. A carlos positivo lo vamos a marear.

    MVP MCT MCTS Daniel Calbimonte

    http://elpaladintecnologico.blogspot.com
    martes, 24 de enero de 2012 13:00
  • Jajajaja muchas gracias a todos por sus sugerencias y colaboración, desde ya la charla de ORM se hizo muy entretenida... siempre aprendiendo algo más.
    Just me
    martes, 24 de enero de 2012 13:45
  • Hola.

    Crea un debate si gustas. Pero preguntando en este foro, lo más a favor que obtendrás de este tipo de herramientas ORM es que, si se dominan y son bien explotadas, tienen un pase, ya que es un punto de vista muy parcial el que tenemos, (salvo excepciones como la de Alberto Población, que es justamente el que da ese límite de contrapunto al dominar ambos campos).

    A mí por ejemplo, no me gustan un pelo, ya que lo normal es que se usen mal (al menos cuando me he topado con ellas), y trasladan al desarrollador/administrador de base de datos (en este caso yo) todo ese ahorro de tiempo que gana el desarrollador de VB.Net (por citar uno).

    Sin embargo, preguntando lo mismo en un foro de desarrolladores puros, lo normal es encontrar justo el punto de vista opuesto. Si bien hay tema para debate, al estar casi todos en el mismo bando, quizá no sea muy enriquecedor.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/ Sígueme en twitter en http://twitter.com/qwalgrande

    martes, 24 de enero de 2012 13:51
    Moderador