Consulta "agrupada"

Muchísimas gracias por contestar, tan sólo quería montar una consulta SQl
que devolviera ese conjunto de resultados, insisto que quizás me expresé
mal al emplear la palabra "formatear". ¿es posible devolver "ese" conjunto
de datos?

Y con respecto a tus comentarios
"... responsabilidades de un motor de base de datos ..."

1; - "... este no debe formatear nada ..."
TOTALMENTE DE ACUERDO

2;- "... y mucho menos tener logica de negocios ..."

Quizás veamos las cosas de forma distinta:

Presentación | Lógica de negocios | Accesos a datos | Base de Datos

Por supuesto que la capa de la lógica de negocios (usualmente una dll que
empaqueta clases) tiene practicamente todo el peso, PERO parte
(ABSOLUTAMENTE TODO LO QUE SE PUEDE HACER EN ESTE CASO CON SQL SERVER
2000) de la responsabilidad la traslado a SQL Server (vistas, sp,
disparadores, T-SQL, reglas, ...), para mantener esas reglas
implementadas, lo que no puedo implementar en SQL Server lo llevo a la
capa de negocios pero por la complejidad de esas reglas y la imposibilidad
de modelarlas en SQL Server que ocurre en la mayoría de los casos por eso
la capa lleva CASI todo el peso, quizás por vicio, quizás por optimizar,
quizás por ver a SQL Server más allá de un almacén de datos, intento
modelar REGLAS DE NEGOCIO en la propia base de datos (hasta extremos
insospechados -> BASE DE DATOS = eqivale modelar una situación donde se
almacenan datos, un mundo, un negocio, un video club, ...)

Gracias por contestar.

Hola, son formas de ver la cosa, yo por lo general cuando veo aplicaciones
que las reglas de negocio estan en la bdd son casi inmantenibles y poco
performantes.
Pero si por ej una regla de negocios de mi aplicacion indica que si un
cliente no tiene credito no se le pueda facturar, eso lo pongo en mi capa
de negocios y no en un trigger o Store



Salu2

Microsoft MVP SQL Server
Culminis Speaker

"dgironal" escribió en el mensaje
news:

Muchísimas gracias por contestar, tan sólo quería montar una consulta SQl
que devolviera ese conjunto de resultados, insisto que quizás me expresé
mal al emplear la palabra "formatear". ¿es posible devolver "ese"
conjunto de datos?

Y con respecto a tus comentarios
"... responsabilidades de un motor de base de datos ..."

1; - "... este no debe formatear nada ..."
TOTALMENTE DE ACUERDO

2;- "... y mucho menos tener logica de negocios ..."

Quizás veamos las cosas de forma distinta:

Presentación | Lógica de negocios | Accesos a datos | Base de Datos

Por supuesto que la capa de la lógica de negocios (usualmente una dll que
empaqueta clases) tiene practicamente todo el peso, PERO parte
(ABSOLUTAMENTE TODO LO QUE SE PUEDE HACER EN ESTE CASO CON SQL SERVER
2000) de la responsabilidad la traslado a SQL Server (vistas, sp,
disparadores, T-SQL, reglas, ...), para mantener esas reglas
implementadas, lo que no puedo implementar en SQL Server lo llevo a la
capa de negocios pero por la complejidad de esas reglas y la
imposibilidad de modelarlas en SQL Server que ocurre en la mayoría de los
casos por eso la capa lleva CASI todo el peso, quizás por vicio, quizás
por optimizar, quizás por ver a SQL Server más allá de un almacén de
datos, intento modelar REGLAS DE NEGOCIO en la propia base de datos
(hasta extremos insospechados -> BASE DE DATOS = eqivale modelar una
situación donde se almacenan datos, un mundo, un negocio, un video club,
...)

Gracias por contestar.

Maxi,

Hay mucha discrepancia acerca de donde deben ser implementadas las reglas
de negocio. Incluso hay discrepancia acerca de qué debe considerarse una
regla de negocio y qué no.

Por mi parte, implemento parte de las reglas de negocio dentro de la base
de datos y parte fuera. El criterio que uso es sobre todo el rendimiento y
la mantenibilidad. Hay veces en las que una regla de negocio es más
eficiente, incluso más limpio implementarla en la propia base de datos y
hay otras en las que es mejor hacerlo fuera.

Pero, desde luego, lo que yo nunca diría es que las reglas de negocio
deban implementarse fuera de la base de datos, ni tampoco lo contrario.

Saludos:

Jesús López
www.solidqualitylearning.com



"Maxi" escribió en el mensaje
news:

Hola, son formas de ver la cosa, yo por lo general cuando veo
aplicaciones que las reglas de negocio estan en la bdd son casi
inmantenibles y poco performantes.
Pero si por ej una regla de negocios de mi aplicacion indica que si un
cliente no tiene credito no se le pueda facturar, eso lo pongo en mi capa
de negocios y no en un trigger o Store



Salu2

Microsoft MVP SQL Server
Culminis Speaker

"dgironal" escribió en el mensaje
news:

Muchísimas gracias por contestar, tan sólo quería montar una consulta
SQl que devolviera ese conjunto de resultados, insisto que quizás me
expresé mal al emplear la palabra "formatear". ¿es posible devolver
"ese" conjunto de datos?

Y con respecto a tus comentarios
"... responsabilidades de un motor de base de datos ..."

1; - "... este no debe formatear nada ..."
TOTALMENTE DE ACUERDO

2;- "... y mucho menos tener logica de negocios ..."

Quizás veamos las cosas de forma distinta:

Presentación | Lógica de negocios | Accesos a datos | Base de Datos

Por supuesto que la capa de la lógica de negocios (usualmente una dll
que empaqueta clases) tiene practicamente todo el peso, PERO parte
(ABSOLUTAMENTE TODO LO QUE SE PUEDE HACER EN ESTE CASO CON SQL SERVER
2000) de la responsabilidad la traslado a SQL Server (vistas, sp,
disparadores, T-SQL, reglas, ...), para mantener esas reglas
implementadas, lo que no puedo implementar en SQL Server lo llevo a la
capa de negocios pero por la complejidad de esas reglas y la
imposibilidad de modelarlas en SQL Server que ocurre en la mayoría de
los casos por eso la capa lleva CASI todo el peso, quizás por vicio,
quizás por optimizar, quizás por ver a SQL Server más allá de un almacén
de datos, intento modelar REGLAS DE NEGOCIO en la propia base de datos
(hasta extremos insospechados -> BASE DE DATOS = eqivale modelar una
situación donde se almacenan datos, un mundo, un negocio, un video club,
...)

Gracias por contestar.

Efectivamente, quizás la experiencia me de otra perspectiva que a día de
hoy no tengo y que intento a través del trabajo diario y en estos foros
(aquí he APRENDIDO muchas cosas que desconocía -> la experiencia de otras
personas) adquirirla, nada es verdad ni nada es mentira.