Sobre las aplicaciones multicapa

Aunque también podríamos usar otros SGBD que hay en el mercado con más
prestaciones que SQL Server.

Y que por cierto supera con creces su precio a sus prestaciones.

Tosdos tenemos en nuestra cabeza como debiera ser un buen SGBD

Lo dudo mucho.

Hombre, no es que pretendamos hacer publicidad al MediaMark, pero supongo
que algun conocimiento tendremos los demas.


Saludos

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 1 Jun 2005 10:03:29 +0200, "José Antonio"
wrote:

Por una parte tienes el SGBD que asegura toda la lógica de negocio y
por otra la aplicación que implementa la lógica de presentación y se
comunica con el SGBD usando SQL. Esto es un típico sistema de dos
capas que funciona estupendamente siempre que el SGBD aguante la carga
de trabajo.

En caso de necesitar más potencia podrías pasar a un sistema de tres
capas descomponiendo la capa del SGBD dos o más capas físicas, y esto
debería de poder hacerse sin tener que tocar la aplicación.



Seguro que esto es lo mas razonable?

Segurísimo.

Y come te aseguras la integridad de los datos?

Con los mecanismos que proporciona el SGBD para hacer eso: dominios,
tablas, claves primarias y secundarias, aserciones, procedimientos
almacenados y tipos definidos por el usuario.

Por cierto Sql Server soporta "assertions" ?

No, lo cual es una seria limitación. SQL Server solo soporta el nivel
de compatibilidad más bajo con el estandar SQL.

Tosdos tenemos en nuestra cabeza como debiera ser un buen SGBD

Lo dudo mucho.

, pero claro
es teoria noy hay nadie con los suficientes para desarrollarlo
practicamente, quizas C omega empiece con unos pinitos pero al final creo
que tampo llegara a ningun sitio.

C omega no tiene nada que ver con un SGBD, pero aunque SQL Server no
soporte "assertions" podemos implementar igualmente cualquier lógica
de negocio con él. Lo único que va a pasar es que nos va a costar más
trabajo hacerlo con procedimientos almacenados.

Aunque también podríamos usar otros SGBD que hay en el mercado con más
prestaciones que SQL Server.


Saludos

On Wed, 1 Jun 2005 11:56:53 +0200, "José Antonio"
wrote:

Aunque también podríamos usar otros SGBD que hay en el mercado con más
prestaciones que SQL Server.

Y que por cierto supera con creces su precio a sus prestaciones.

Eso es siempre relativo, depende de como valores el dinero y las
prestaciones.

Para muchas empresas el coste de un SGBD de gama alta no es un
problema, pero sus prestaciones son muy importantes.

Tosdos tenemos en nuestra cabeza como debiera ser un buen SGBD

Lo dudo mucho.

Hombre, no es que pretendamos hacer publicidad al MediaMark, pero supongo
que algun conocimiento tendremos los demas.

Pero la realidad es que hay muy poca gente que sepa como debería ser
un buen SGBD.

El mejor libro que se ha escrito sobre este tema es sin ninguna duda
este:

http://www.amazon.com/exec/obidos/t...7?v=glance


Está previsto que la tercera edición se publique a finales de este
año.


Saludos

Hola,

Te recomiendo que no saques la capa de Datos y si tu idea es hacer
sentencias dinámicas
para los métodos CRUD (Create, Read, Update, Delete) te recomiendo que lo
hagas en
esa misma capa. Por otro lado te dijo que generar sentencias SQL dinámicas
es mucho mas lento que los SP del SQl. y si mañana necesitas modificar algo
sabes específicamente
donde ir.

Fabián Imaz
Jefe de Proyectos
(Messenger)
www.d2bnetwork.com
d2B Network Uruguay
Canelones 2047

Tel.: +598 2 4085093
Montevideo - Uruguay
"Benton" escribió en el mensaje
news:

Hola,

Estoy analizando un ejemplo de aplicación en tres capas, para usarlo como
modelo en un proyecto que tengo enfrente.

La capa de más bajo nivel es la que realiza las operaciones en la base de
datos, esta capa la constituyen básicamente un montón de procedimientos
almacenados que se encargan de insertar, modificar, elinimar y extraer
registros de la tablas.

La capa intermedia (en C#) manda llamar a estos procedimientos con los
parámetros adecuados.

Ahora bien, mi idea es eliminar la capa "baja" y hacer que la capa
intermedia, en vez de llamar procedimientos almacenados, genere
dinámicamente el SQL que necesita en cada operación y lo ejecute. De esta
manera me evito crear y mantener cuatro o cinco procedimientos por cada
tabla.

¿Alguien tiene alguna opinión sobre lo atinado o desatinado de mi idea?

Saludos,

-Benton

On Wed, 1 Jun 2005 09:26:51 -0300, "Fabian Imaz"
wrote:

Te recomiendo que no saques la capa de Datos y si tu idea es hacer
sentencias dinámicas
para los métodos CRUD (Create, Read, Update, Delete) te recomiendo que lo
hagas en
esa misma capa. Por otro lado te dijo que generar sentencias SQL dinámicas
es mucho mas lento que los SP del SQl. y si mañana necesitas modificar algo
sabes específicamente
donde ir.

Esto es un galimatías.


Saludos

Te recomiendo que no saques la capa de Datos y si tu idea es hacer
sentencias dinámicas
para los métodos CRUD (Create, Read, Update, Delete) te recomiendo que lo
hagas en
esa misma capa. Por otro lado te dijo que generar sentencias SQL dinámicas
es mucho mas lento que los SP del SQl. y si mañana necesitas modificar
algo sabes específicamente
donde ir.

De hecho ese punto se menciona en el ejemplo.

Presumiblemente, usar procedimientos almacenados es más eficiente porque
éstos ya estarán pre-compilados junto con su plan de ejecución en el SGBD.
Generar el SQL dinámicamente le tomaría tiempo al grupo de clases en C# que
representan las tablas, aunque supongo que en tiempo de ejecución serían
fracciones de segundo. Amén de que, presumiblemente también, el SGBD tendría
que analizar cada sentencia SQL para determinar el plan adecuado cada vez
que va a ejecutarla.

Ahora bien, esto último me trae a la memoria el asunto del "Prepare" que
debe hacer el SGBD, esa especie de "caché del plan" que evita analizar la
misma sentencia cada vez que se ejecute. ¿Resolvería esto la cuestión de si
los procedimientos almacenados son mejores?

Saludos,

-Benton