¿Programo bien?

Hay más formas de precompilar como por ejemplo vistas y preparación de
consultas. Además el tiempo de compilación no suele ser muy
significativo. Si reduces el tiempo de una consulta en 50 milisegundos
nadie te lo va a agradecer.

Cierto si trabajás con bases pequeñas y de relaciones simples. Hay bases de
datos que debido a volumenes de información que almacenan y a la cantidad de
consultas simultáneas que deben responder exigen hasta el más mínimo ahorro
de tiempos. 50 milisegundos en una consulta pueden significar errores por
timeout debido a los bloqueos que un query debe ejecutar en la base y que
crecen exponencialmente en función de la cantidad de concurrencias que se
deben soportar.

Por lo demás, no hay muchas otras correcciones particulares que hacer. Pero
sí suele ser un error común y muy general de los desarrolladores pensar que
hay "una manera mejor" a todas las demás y olvidarse de que no hay soluciones
que puedan ser evaluadas prescindiendo del contexto en el que se da el
problema.



"Alfredo Novoa" wrote:

On Wed, 31 Jan 2007 08:17:47 -0400, "Carlos"
wrote:

>> Y meter sistematicamente las consultas dentro de procedimientos
>> almacenados es otro absurdo.
>>
>
>Significa que conviene usar los SP's principalmente para acciones de
>actualización ?

No, lo que conviene es no usar los SP. La mayoría de los SP que se
necesitan son triggers y también conviene usarlos lo menos posible.

Ahora mismo estamos pasando una aplicación vieja de DBase a SQL Server
y gracias a las vistas indexadas apenas estamos necesitando triggers
ni SP.

Estamos eliminando un montón de código de la aplicación que no se
convierte en código de servidor. Simplemente ya no es necesario
gracias al mayor nivel de abstracción de la programación declarativa.

> y que las consultas deberían enviarse directamente desde
>la aplicación? No "amarraría" esto más a la aplicación con el SGBD?

No. ¿Que diferencia hay entre "amarrarse" a tablas que a SP?

Lo que si hay que hacer es aprovechar el sistema de permisos, las
vistas, los alias, etc.

>Considerando la ventaja de pre-compilación que aportan los SP's, no
>convendría también tener las consultas más complejas/frecuentes en SP's?





>ok. Eso lo tengo claro. Las reglas de integridad de los datos y de sus
>datos derivados deben ser responsabilidad unica y exclusiva del SGBD ya que
>eso independiza los datos y su integridad, de la aplicación.

Exacto, y además le estamos danto oportunidades al optimizador para
hacer su trabajo.

>> 2) La interfaz se ocupa de presentar los objetos de la base de datos a
>> los usuarios, comunicandose con el SGBD a través del lenguaje SQL.
>
>Ok pero siguiendo el mismo ejemplo, aunque entendemos que es muy trivial, de
>que otra manera se pueden "presentar los objetos" en la interfaz si no es de
>forma parecida a la que propone el compañero?

Con datasets, y datatables.

> es decir mapeando la entidad
>cliente como una clase (objeto) en la aplicación.

No se puede mapear una tabla con una clase por que es absurdo, lo que
se hace es mapear una tabla con un objeto de tipo colección.

> Tienes otra alternativa
>para eso mismo, o ejemplo?

Un datatable directamente conectado por DataBindings a los controles
visuales.

No tiene ningún sentido hacer algo como esto:

miCliente.Dni = txtDni.Text;
miCliente.Nombre = txtNombre.Text;
miCliente.Grabar();

Cuando se usan "databindings"

>nota:Disculpa la insistencia, es que me interesa profundizar en este tema
>con fines de aclarar conceptos que tengo un poco confusos.

No hay nada que disculpar. Pregunta lo que quieras que yo responderé
lo que me de la gana :-)


Saludos
Alfredo

Disculpa la intromisión pero me sorprendió tu exposición anti-SP's.

Y meter sistematicamente las consultas dentro de procedimientos
almacenados es otro absurdo.

Significa que conviene usar los SP's principalmente para acciones de
actualización ?

No, lo que conviene es no usar los SP. La mayoría de los SP que se
necesitan son triggers y también conviene usarlos lo menos posible.

No usar SP's ???!!! Para mi estás absolutamente equivocado.
No sé qué relación ves entre un SP y un trigger ya que son conceptos
totalmente distintos. Si te refieres a la integridad declarativa,
fríamente hablando los SP's no tienen nada que ver. Los triggers, como las
restricciones (check, relaciones...) sí son para mantener integridad. Un
trigger puede llamar un SP que ayude a su propósito, pero que lo haga o no
es irrelevante para los fines de la integridad.
La principal ventaja de usar SP's es la misma que la de usar procedimientos
o métodos en cualquier ambiente de programación: encapsular lógica por su
complejidad o por su reusabilidad. Te parece poco eso??!!
Otra ventaja: Los SP's (y también las funciones de usuario) guardan el plan
de ejecución, eficientizando así el desempeño del servidor.
Otra ventaja: La seguridad. Ej. Puedes desarrollar un sistema sin conceder
a determinados usuarios (o a ninguno) acceso de modificación a las tablas
del sistema. Sin embargo puedes establecer el acceso a través de SP's
controlados, dando sólo acceso de ejecución a esos SP's.
Otra ventaja: Independizar la Base de Datos de las distintas aplicaciones.
Cualquier aplicación para ejecutarlos solo debe conocer los parámetros de
llamada a los SP's y los conjuntos que devuelven o la accion final que
producen. Esto aunque (en un caso extremo) no conozcan siquiera la
estructura de las tablas.

Ahora mismo estamos pasando una aplicación vieja de DBase a SQL Server
y gracias a las vistas indexadas apenas estamos necesitando triggers
ni SP.

Bueno, si estás hablando de triggers para acumular cantidades o balances (y
agilizar consultas), pues claro que con una vista indexada puedes evitarlos.
Pero, primero, los triggers no son sólo para ese de tipo cálculos
redundantes y ,segundo, las vistas indexadas tampoco abarcan muchas
situaciones diversas que ayuden al control de integridad (puedes revisar
acerca de sus limitantes). Por sólo citar algo simple: actualizar un
estatus, controlar un límite de crédito, controles de auditoría,
actualización cruzada, etc. etc.
Una vista indexada básicamente te servirá para agilizar consultas de
valores acumulados. Su ámbito es muy limitado.

Estamos eliminando un montón de código de la aplicación que no se
convierte en código de servidor. Simplemente ya no es necesario
gracias al mayor nivel de abstracción de la programación declarativa.

Depende de la aplicación que estés desarrollando. Sin duda que para
aplicaciones simples se aplica perfectamente lo que dices. De todos modos,
con cada nueva versión de los SGBD el nivel de abstracción se incrementa
(ej. las consultas recursivas de SQL 2005) y el código que antes estaba en
SP's y triggers puede ahora ser parte declarativa del servidor.

y que las consultas deberían enviarse directamente desde
la aplicación? No "amarraría" esto más a la aplicación con el SGBD?

No. ¿Que diferencia hay entre "amarrarse" a tablas que a SP?

Lo que si hay que hacer es aprovechar el sistema de permisos, las
vistas, los alias, etc.

Lo sospechaba. Ya veo que es evidente que has visto pocas consultas
complejas o quizás sólo has trabajado con aplicaciones pequeñas y/o de pocos
usuarios. Hay determinadas consultas que requieren una lógica de
pre-procesamiento que definitivamente no puede establecerse en una simple
vista (view). Son a veces necesarias tablas temporales, cursores, variables,
estructuras de control, iteraciones, etc. en fin todo lo que envuelve T-SQL
que por si no sabías es también un lenguaje de programación. Aquí entra lo
de encapsular esa lógica en un SP del servidor para que éste se encargue de
todo el proceso de forma transparente a la aplicación cliente.
También ignoras el importante tema de la seguridad que resulta de dar acceso
a un SP y no necesariamente a una tabla ni a sus campos en determinados
casos.

Considerando la ventaja de pre-compilación que aportan los SP's, no
convendría también tener las consultas más complejas/frecuentes en SP's?

Hay más formas de precompilar como por ejemplo vistas y preparación de
consultas. Además el tiempo de compilación no suele ser muy
significativo. Si reduces el tiempo de una consulta en 50 milisegundos
nadie te lo va a agradecer.

Tienes razón... pero poca:). No sabes lo que es el plan de ejecución y el
costo total una consulta en SQL Server? qué tal si fuesen varias
pre-consultas o consultas multi-set encapsuladas en un mismo SP? qué tal si
la cantidad de usuarios concurrentes se incrementa significativamente ?
Piensas que (siguiendo tu ejemplo) 50 milisegundos en cada petición al
servidor no sería significativo? Insisto, no creo que hayas trabajado con
aplicaciones muy grandes ni con muchos usuarios, ya que estas cosas empiezan
a preocuparnos cuando nos topamos con esos casos.
Pero.. no te culpo, yo también ignoraba esas cosas cuando trabajaba sólo con
pymes. Si no es tu caso, me disculpas pero debes revisar esa idea errónea
que tienes sobre los SP's y la precompilación de los planes de ejecución.

ok. Eso lo tengo claro. Las reglas de integridad de los datos y de sus
datos derivados deben ser responsabilidad unica y exclusiva del SGBD ya
que
eso independiza los datos y su integridad, de la aplicación.

Exacto, y además le estamos danto oportunidades al optimizador para
hacer su trabajo.

Precisamente por el optimizador también son convenientes los SP's.

No se puede mapear una tabla con una clase por que es absurdo, lo que

se hace es mapear una tabla con un objeto de tipo colección.

Objeto de tipo colección, pero de qué? de objeto de un tipo de clase que
mapea una tabla ? No estarás diciendo lo mismo que dices que es absurdo?

nota:Disculpa la insistencia, es que me interesa profundizar en este tema
con fines de aclarar conceptos que tengo un poco confusos.

No hay nada que disculpar. Pregunta lo que quieras que yo responderé
lo que me de la gana :-)

Jeje sin duda que esta vez respondiste lo que te dio la gana. Te
recomiendo que profundices un poco más sobre los Store Procedures ya que tus
argumentaciones me parecen exageradamente pobres al respecto.
Claro, no eres el único, hay peores argumentos contra los SP's.


Saludos

Ricardo Passians

On 31 Jan 2007 10:36:43 -0800, "Paco Ferre"
wrote:

Hola, yo no diría que está mal, solo que es mucho trabajo...

Mucho trabajo significa menos tiempo y menos dinero y eso está muy muy
mal :-)

A no ser que cobres por horas, claro, y de eso hay mucho.

Por tanto el sistema está basado en una clase BaseNegocio de la que
heredan todos los objetos de negocio de la aplicación.
...

Por tanto la traducción de:
miCliente.Dni = txtDni.Text;
miCliente.Nombre = txtNombre.Text;
miCliente.Grabar();

sería (aunque ya ni necesito hacerlo así):
miCliente["Dni"] = txtDni.Text;
miCliente["Nombre"] = txtNombre.Text;
miCliente.Grabar();

O sea, que esto es todavía peor.

Te pongo aquí el código que escribo yo para hacer eso:

Pero con esto evito hacer los get/set con los 20 campos y además el
this["PuedeSerDeCualquierCosaAunqueNoSeaUnCampo"]

Y yo me evito crear las "clases de negocio" y el asignar las
propiedades a mano.

Si quieres asignar propiedades a mano por código, cosa que no es nada
recomendable, entonces puedes usar un dataset tipado y el VS te crea
todos los gets y sets automáticamente.

BaseNegocio acaba haciendo un montón de trabajo (mucho foreach para
leer, guardar, crear, eliminar, buscar, permisos de usuario...) que no
hay que programar una y otra vez en las clases "hijas" y para el resto
del "trabajo" existen métodos virtuales que se pueden sobreescribir en
cada clase.

Yo no tengo que escribir nada de código para todas estas cosas.
Simplemente asignar algunas propiedades en los componentes.

(Obviamente existe un mecanismo para poblar una colección de objetos a
partir de un DataTable, y muchas cosas más).

Pero si ya tienes los datos en un DataTable, para que quieres otra
colección de objetos. El DataTable ya es una colección de objetos que
además permite el "DataBinding".

Aparte de esto, para la interacción con el usuario, existen controles
de usuario que se encargan de leer y escribir datos en las clases de
negocio antes de ser guardadas, o sea controles que heredan o son
compuestos de; TextBox, ComboBox, CheckBox, HyperLink, Button,
LinkButton, DataGrid, DataList, UserControl...

Yo puedo usar los controles de .NET sin cambiarles nada.

No digo que sea perfecto, ni que no me haya causado problemas. Pero
estoy contento ya que en cada nuevo proyecto, solo tengo que
preocuparme de lo realmente importante de la aplicación, o sea, de
todo menos la "fontanería", jeje.

Pues yo veo un montón de fontanería innecesaria.

Por otro lado también es una gozada encontrar un error y saber que
solo tengo que arreglarlo en la clase o el control base para que no se
vuelva a producir en cualquier otra parte de la aplicación.

Para mi es una gozada el no tener que crear un montón de código que
luego puede fallar.


Saludos

On Wed, 31 Jan 2007 19:08:45 +0100, "Alberto"
wrote:

Otra de las ventajas de usar SP es que ciertas modificaciones son
transparentes al usuario. No es necesario volver a compilar la aplicación y
volverla a instalar.

Lo mismo que si cambias tablas o índices.

Saludos

On Wed, 31 Jan 2007 19:13:05 +0100, "Alberto"
wrote:

No tiene ningún sentido hacer algo como esto:

miCliente.Dni = txtDni.Text;
miCliente.Nombre = txtNombre.Text;
miCliente.Grabar();

El dataBinding está muy bien pero tal y como lo hago yo tienes independencia
de la capa de presentación.

¿Y eso que quiere decir?

¿Quien es independiente de la capa de presentación?

Destrás de la capa de presentación ya solo está el usuario.

Hecha la capa de negocio, hacer un interface
para windows o web me supone poco esfuerzo...y por no hablar de la extrema
claridad del código.

Ya, y a mi hacer la capa de negocio dentro del SGBD me supone mucho
menos esfuerzo que a alguien que la programe en un lenguaje de bajo
nivel no orientado a bases de datos como C#.

Saludos