Hola Carlos, no veo porque hcaer las cosas fuera de los patrones normales, la mayoria (es mas no vi en 15 años otra cosa) resoluciones de jerarquias se resuelven en la entidad de datos, yo lo haria justamente en ese lugar ya que es parte del modelado de datos y no de objetos, en 2008 si lo quieren hacer mas simple usen datos jerarquicos, pero modelar esto fuera de la base de datos es algo asi como armar una sola tabla con un campo xml y ahi dentro la entidad cliente, esto es algo no recomendado por la industria en general y veras cientos de ejemplos de jerarquias que siempre se resuelven del otro lado (BDD), quizas vale la pena el ejercicio del TDD nada mas, pero no lo usaria.
Ademas si te cambian el servicio no es problema porque el modelado standard de jerarquias es soportado por todas las bases de datos serias. El día 9 de octubre de 2009 12:52, Carlos Peix <[email protected]> escribió: > Ya se que es una lista de bases de datos, ya se, pero no me aguanto. > Pensa dos veces antes de armar esa logica basandote en una caracteristica de > una base de datos. Yo lo pondria del lado de la aplicacion (del modelo)... > ...a menos, que tengas un contrato que diga que si te cambian el servicio de > base de datos estas autorizado a tomarte cinco años de vacaciones en el > lugar que elijas :-) > ---------------------------------- > Carlos Peix > > 2009/10/9 Carlos A. Schroeter <[email protected]> >> >> Gracias Mariano >> >> La verdad es que es un tema bastante complejo y sobre el que hay que >> investigar bastante antes de tirarse de cabeza. >> >> Tomé el ejemplo de CTE que me pasó Maxi y aparentemente resuelve una parte >> de la cuestión, voy a tratar de ampliar el caso para ver más resultados >> >> Ya mismo me fijo en el link que me pasaste y veo qué me puede aportar >> >> Gracias nuevamente >> >> Carlos >> >> >> >> De: [email protected] [mailto:[email protected]] En nombre de Jose >> Mariano Alvarez >> Enviado el: Jueves, 08 de Octubre de 2009 22:25 >> Para: Carlos A. Schroeter >> Asunto: [dbadmin] Recursividad en SQL (Armado de productos) >> >> >> >> Deberias tener en cuenta varias cosas importantes. >> >> Algunas las sufri por eso te cuento >> >> >> >> El tipo de dato que se agrego en SQL Server 2008 y que te sugiere Maxi >> sirve muy bien para estructuras jerarquicas compatibles con grafos dirigidos >> sin ciclos, mas exactamente con arboles y deberias investigar bien porque >> hasta donde me acuerdo me parece que no sirve para tu caso en particular >> donde un nodo podria tener mas de un padre como por ejemplo cuando un >> producto puede estar como producto y como parte constitutiva de otros >> productos. >> >> >> >> Por ejemplo B en la siguiente estructura tiene como padres A y E >> >> >> >> A se compone de B C y D >> >> E se compone de B y G >> >> G se compone de A y M >> >> >> >> En el caso de tener un producto como parte constitutiva de otro producto >> se debe tener en cuenta que no existan ciclos indirectos en la definicion >> como en siguiente caso A->C C->G G->A >> >> >> >> A se compone de B C y D >> >> C se compone de B y G >> >> G se compone de A y M >> >> >> >> >> >> Se debe tener en cuenta que la recursion de T-SQL tiene pocos niveles >> salvo en el caso de Common Table Expressions o de procedimientos o funciones >> en CLR disponibles estos dos en 2005 y 2008. >> >> >> >> Existe un libro de Joe Celko de ANSI 92 especializado en estos temas. >> >> >> http://www.amazon.com/exec/obidos/ASIN/1558609202/qid%3D1111545856/sr%3D11-1/ref%3Dsr_11_1/103-9443562-6561454 >> >> >> >> >> >> Espero sirva. >> >> >> >> -- >> -------------------------------- >> Ing. José Mariano Alvarez >> http://blog.josemarianoalvarez.com/ >> http://twitter.com/JoseMarianoA >> Microsoft MVP >> >> SQL Total Consulting >> >> >> >> >> 2009/10/8 Carlos A. Schroeter <[email protected]> >> >> Hola Grupo >> >> Estoy buscando en la web el manejo de la recursividad y nada de lo estoy >> viendo me termina de cerrar >> >> La necesidad hoy es resolverlo con SQL 2000 y en el peor de los casos >> migrar a SQL 2005 >> >> Se trata de resolver una cuestión en un sistema de producción, en donde >> participan una serie de productos terminados (fabricados), que para su >> fabricación se implementan formulas. Por ejemplo, fabrico una PC >> >> Una PC se fabrica con 1 Monitor, 1 teclado, 1 mother, 2 Memorias, 1 Placa >> de Video, etc. (formula del producto terminado PC) >> >> Primera Cuestion: Tambien se fabrica el teclado…..y un teclado se fabrica >> con 104 teclas, 1 placa, etc. Etc. (formula del producto Teclado) >> >> Segunda Cuestion: pueden existir n cantidad de niveles ya que un producto >> puede tener otros con sus formulas y estos otros productos con sus >> correspondientes formulas >> >> En los ejemplos que he visto quizá puedan resolver la consulta que me >> devuelva la lista de componentes de un determinado producto….pero no >> resuelven cuestiones tales como la actualización de las formulas…es decir, >> si modifico una formula que dicha modificación impacte en todos los >> productos que la contienen. >> >> Alguien ha tenido experiencia en este tema y ha logrado resolverlo? >> >> Desde ya muchas gracias >> >> Carlos A. Schroeter >> >> >> >> >> >> >> >> >> >> >> >> > -- ----------------------------------------------------------- Microsoft MVP en SQL Server Consultor en SQL Server http://blog.maxiaccotto.com -----------------------------------------------------------
