¿Programo bien?

On Wed, 31 Jan 2007 20:44:00 -0400, "Ricardo Passians"
wrote:

Si, pero son la peor y más primitiva forma de encapsular lógica de las
que dispone un SGBD.

A mi me luce que hablas de algo muy distinto que no comprendo qué es. Lo
digo porque esa afirmación está totalmente fuera de lugar para lo que
estamos discutiendo aquí.

Esta afirmación es la clave de la discusión. Los SP son evidentemente
procedimentales y a lo que se debe de dar preferencia es a la
programación declarativa. Esto es básicamente lo que quería decir
desde el principio. No me parece tan difícil de entender.

Si en algún caso especial conviene usar un SP debido a limitaciones
del sistema o a cualquier otra cosa, pues se usa y ya está. Pero
sabiendo que estamos haciendo una excepción a la regla teórica
general. La regla que viene en todos los libros de teoría de bases de
datos.

Bueno, pues parece que hay miles de situaciones que no se pueden hacer "de
otra manera" en un SGBD normal. A la fecha actual.

Seguro que no hay tantas.

Sip... hay mas formas... pero los SP's lo hacen de manera automática y
transparente al usuario o al administrador y de forma más persistente que
las demas. No es eso una ventaja?

Es una desventaja por que no puedes controlar lo que pasa. Además eso
es solo una peculiaridad de SQL Server. No tiene por que ser así
siempre.

Una consulta se prepara con una linea de código. No me parece buen
negocio perder el control sobre lo que pasa por ahorrarme una línea.

A veces hasta me da risa como defiendes tus argumentos como en un esfuerzo
de "no perder nunca". Amigo, reconozca sus errores que nadie es infalible.

Pero si es evidente que en esto tengo razón.

"De vez en cuando" no es lo mismo que tener "cada vez" que preparar
manualmente cuando se requiera postear una consulta, como sugieres en tus
mensajes. En todo caso, la administración normal de un SGBD implica por
ejemplo, regenerar las estadísticas periódicamente, reconstruir o agregar
índices recomendados, recompilar los sp's, etc. etc. pero... esas no son
labores por las que debamos preocuparnos frecuentemente ni los programadores
ni los DBA's.

O sea que tu maravilloso automatismo que ahorra una línea obliga al
DBA a recompilar los SP periódicamente.¡Menuda ventaja!

Otra vez igual. Puedes crear diferentes vistas externas de la base de
datos y enseñar una vista distinta a cada aplicación.

por supuesto y los sp's, como los views, permisos, etc. contribuyen a
eso.

Los SP son innecesarios para esto y he visto montones de casos en los
que se usan muy mal para intentar ocultar la vista relacional debajo
de una capa procedimental. El primer mensaje de este hilo tenía toda
la pinta de ser eso.

Si, están horriblemente limitadas en la versión actual de SQL Server,
pero muchas de esas limitaciones se pueden superar con un poco de
imaginación.

Me encantaria ver tus ejemplos especificos sobre esa tan "imaginativa"
afirmación.

Es sencillo, y hasta te lo dice la documentación. Puedes construir
consultas que saquen datos de varias vistas indexadas para ir
construyendo el resultado final que te interesa. Al final la ganancia
de velocidad sigue siendo muy grande cuando hay muchos agregados.

Por si no sabías, las vistas indexadas no surgieron en esta
versión. Tienen ya unos añitos de existencia.

Ya lo sabía, pero no se a que viene esto. Las vistas materializadas de
Oracle tienen muchos más y son más potentes.

Claro, de eso se trata. A SQL Server todavía le queda muchísimo por
mejorar, pero ese es el camino que hay que seguir: de procedimental a
declarativo.

De acuerdo.

Pues eso, que primero buscas la solución declarativa y si no se puede
pues recurres a los SP. Es decir que conviene evitar los SP.

Cuanto mejor es el SGBD menos consultas de ese tipo hay.

Recomienda uno, hace tiempo que lo busco.

Te aviso cuando acabe el mio :)

Pero aun con todas las limitaciones de los SGBD actuales esto ocurre
mucho menos de lo que la mayoría de la gente piensa.

Insisto, depende del tipo de aplicaciones con que te enfrentes.

¿Podrías poner algún ejemplo de una consulta que necesite SP?

Si hablamos estrictamente de consultas de solo recuperacion de datos, que
"necesiten SP" son obviamente menos que las que los necesiten.

Obviamente :)

Pero algunos ejemplos podrían ser:

1-Especifico: Generar la tabla de amortización de un préstamo.

Hombre, si no sabes hacer esto sin un SP entonces me explico muchas
cosas.

2-Especifico: Calcular los balances de las cuentas a un nivel de profundidad
específico (dada una relación reflexiva de la entidad "cuenta")

No se muy bien lo que quieres decir con la relación reflexiva de la
cuenta, pero para calcular balances yo no necesito ningún SP.

Para hacer un escandallo se echa de menos el operador de cierre
transitivo. Disponiendo de ese operador genérico (que podría ser un
SP) ya no necesitamos otros SP para eso.

3-Mas genericos: a) Por limitaciones del SGBD: como subconsultas que
requieran varios group by y haya que usar una tabla temporal o variable tipo
table intermedia. Tambien los TOP tienen ciertas limitaciones en la
construcción de consultas y asi por estilo.
b) Por eficiencia para tablas voluminosas: Donde
sea mas eficiente (por plan de ejecución), traer algún dato puntual de una
tabla por su PK, y cargarlo a una variable para filtrar la(s) consulta(s)
posterior(es) y evitar seeks o scans innecesarios.

Excepciones y limitaciones del SGBD. Lo normal es que no hagan falta
los SP.

c) Reutilización del código de SP's: Cuando
requiera llamarse un SP ya existente como entrada de otras consultas
... d) Tambien por eficiencia: Combinar
actualización y consulta en un sólo "viaje" al servidor. Yo tengo por ej.
SP's de actualización que luego de la lógica que actualiza, me devuelven un
set con datos frutos de un select o de una llamada a otro SP o funcion.
Ahorra tiempo innecesario.
...
,,, y asi por el estilo.

Esto ya son chorradillas. Si quieres usar un SP en vez de una
multiconsulta en un caso determinado para ahorrar algún milisegundo
pues vale.

Esos serian casos donde se podrian "necesitar". Pero en mi caso por las
multiples ventajas expuestas los uso tambien donde no solo se "necesiten"
sino tambien donde sean altamentes favorecedores de la encapsulación, de
claridad del código, de la seguridad y de la optimización del desempeño.

Pero el código declarativo lo es más.

En mi respuesta yo me basé en esta frase que escribiste: "¿Que diferencia
hay entre "amarrarse" a tablas que a SP?"

Depende de como sean los SP. Si se mantiene la propiedad del cierre
relacional entonces da igual.

Mira yo uso vistas también, muchas y frecuentemente.
Nadie dice que no se pueda hacer con vistas. Solo cito (lo repito) como una
ventaja agregada de un SP la facilidad para la seguridad y tambien la mayor
fortaleza a la inyección de código. Mantener los permisos a una tabla (o a
una vista, ya que insistes) requiere mayor trabajo que a un SP que haga lo
mismo (ej. devolver una lista de clientes en mora), ya que los SPs en si
mismos no son objetos actualizables como las tablas y vistas. Sobre la
inyección de código normalmente los front-ends controlan mejor las llamadas
a SPs (suele haber instrucciones separadas para ellos) que a simples
consultas abiertas aunque estas sean "preparadas". Si estas no son ventajas
bueno allá tu que no lo quieras ver así en tu inútil esfuerzo por sustentar
tus ideas.

Son pijotadas que no cambian la regla general.

No estoy diciendo eso. Hasta sin preparar, si repites la misma consulta de
forma consecutiva, el servidor normalmente te guarda el plan en caché. Sólo
que con los SP's no hay que hacerlo manualmente. Lo hacen automáticamente en
la primera ejecuciojn y ademas persisten al cierre de la conexión de los
clientes, no se guardan solo en el cache por un tiempo. Eso es para mi una
grandísima ventaja sobre todo en consultas complejas, frecuentes y
concurrentes.

Lo que dices es absurdo. El plan de una consulta frecuente estará casi
siempre en la caché, así que no se gana nada.

Pero te aclaro que la pregunta te la hice porque me dio la impresion que
cuando hablabamos de pre-compilacion no te referias al plan de ejecucion y
costo de la consulta. De hecho nunca mencionaste el termino propiamente. Por
eso pense que no conocias ese tema.

Ah, vale, entonces aclarado.

La verdad que no parece. O al menos no fuiste el encargado de implementar
esas aplicaciones.

Pues si fui yo. Pero teníamos un montón de servidores de datos en
paralelo con doble procesador funcionando 24 horas, así que no nos
teníamos que preocupar mucho por ese tipo de pijotadas de si el plan
de ejecución era persistente o no.

Malentendiste lo que dije pero esta bien. Allá tú. En vez de un SP's
prefiere mejor preparar cada consulta antes de postearlas al servidor.

No hombre, prepararlas al arrancar la aplicación. Eso ahorra el tener
que recompilar los SP. Vuelves a preparar las consultas en caliente
cuando quieras y listo.


Saludos

On Thu, 1 Feb 2007 10:02:04 +0100, "Hoze" wrote:

¿Y dices que C# es de bajo nivel?

Comparado con SQL o T-SQL es de muy bajo nivel.

Hay mucha más diferencia entre SQL y C# que entre C# y ILASM.

Aunque con C# 3.0 ya cambian bastante las cosas.

Saludos

On 1 Feb 2007 00:32:30 -0800, "Paco Ferre"
wrote:

Creo que has llegado a conclusiones poco acertadas a partir de lo que
he escrito.
Y además no dices nada concreto de cómo haces las cosas.

Ya lo he dicho. Uso una misma clase para presentar cualquier tabla a
los usuarios sin tener que crear una clase específica para cada
consulta.

Esta clase podría ser DataTable aunque yo uso una hecha por mi, pero
la idea es básicamente la misma: una clase me vale para cualquier
tabla o consulta. A esto le llamo reutilización de código :-)

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

¿Donde?, ¿has adjuntado algún archivo?

Es que no necesito ninguna línea de código para hacer eso :-)

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

¿Podrías explicar cómo?, no me digas que usas el Wizard de Visual
Studio ;D

No, me refiero a que puedo arrastrar al formulario los controles
estandard de la paleta de controles.

El wizard no suelo usarlo pero también podría.

Sobre los triggers y los SPs decir que tienes razón en decir que no
conviene usarlos mucho,

Me alegro de que alguien esté de acuerdo :-)

pero en mi caso el motivo es por comodidad.

Me parece bien. Yo lo decía como consigna genérica. A la hora de
mancharte las manos con el código siempre hay que hacer excepciones al
las reglas teóricas debido a muchas razones (principalmente a
limitaciones del software externo), pero sabiendo lo que haces.

Los triggers hace mucho tiempo que no los uso, me gusta tener el
código de "negocio" en un mismo sitio.

Pero la cuestión es: ¿En que sitio?

Y para los SPs, pueden ser útiles en consultas muy complejas (aunque
también creo que una consulta compleja es síntoma de un mal diseño de
base de datos), o para consultas que no van a cambiar nunca y son muy
utilizadas.

Yo prefiero usar vistas para eso. Por ejemplo en una consulta muy
utilizada el plan suele estar siempre en la caché con lo que no ganas
nada teniendo un plan "persistente". Más bien pierdes por que tendrías
que recompilarlo de vez en cuando en lugar de forzar una preparación
de la consulta.

Alfredo, ¿no serás de Madrid o periferia?

Madrid centro.

, la verdad es que sería
interesantísimo quedar un grupo, escuchar distintas opiniones y pensar
en nuevas ideas.

Pues encantado, puedes escribir mi dirección de correo cuando quieras.
En persona este tipo de discusiones son mucho menos agrias.


Saludos
Alfredo

Esta afirmación es la clave de la discusión. Los SP son evidentemente
procedimentales y a lo que se debe de dar preferencia es a la
programación declarativa. Esto es básicamente lo que quería decir
desde el principio. No me parece tan difícil de entender.

Tu tienes como una psicosis "anti-procedimental". No te das cuenta que
"programación declarativa" como dices es un concepto también dependiente de
la implementación del SGBD particular. Lo que en un SGBD es declarativo en
otro puede ser procedimental (según el alcance que le estés dando tú al
término).
Además, parece como si pensaras que los SP's por ser procedimentales
(internamente) no son objetos del SGBD. Será que piensas que los SP's
pertenecen a la aplicación y no al servidor?
Dime a ver, si yo defino una función de usuario (que es procedimental, no?)
y la incluyo en una restricción check de una tabla. Es declarativa o
procedimental esa restricción?
Por otro lado, deberías leer sobre el concepto "abstracción".

Si en algún caso especial conviene usar un SP debido a limitaciones
del sistema o a cualquier otra cosa, pues se usa y ya está. Pero
sabiendo que estamos haciendo una excepción a la regla teórica
general. La regla que viene en todos los libros de teoría de bases de
datos.

Yo lo que pienso es que tú no has sobrepasado la teoría básica y primitiva
(aunque todavía actual) de las bases de datos y te has descuidado de revisar
bien las implementaciones de esa teoría (los SGBD's). Te pareces a algunos
profesores universitarios que no pasan de ahí y se mantienen obsoletos en un
sueño del que no despiertan.

Bueno, pues parece que hay miles de situaciones que no se pueden hacer "de
otra manera" en un SGBD normal. A la fecha actual.

Seguro que no hay tantas.

Sip... hay mas formas... pero los SP's lo hacen de manera automática y
transparente al usuario o al administrador y de forma más persistente que
las demas. No es eso una ventaja?

Es una desventaja por que no puedes controlar lo que pasa. Además eso

Jejeje.. Eres un caso de psiquiatra. En este caso, sorpresivamente sí te
interesa controlar lo que pasa (manualmente) y no dejárselo al SGBD, como en
el caso de la integridad declarativa. Tus razonamientos son a veces
risiblemente contradictorios.

Una consulta se prepara con una linea de código. No me parece buen
negocio perder el control sobre lo que pasa por ahorrarme una línea.

No tienes ni idea de lo que estás hablando.

A veces hasta me da risa como defiendes tus argumentos como en un esfuerzo
de "no perder nunca". Amigo, reconozca sus errores que nadie es infalible.

Pero si es evidente que en esto tengo razón.

Evidente para ti. Ya te voy conociendo mejor. Te repito: Lo tuyo es la
teoría pura de bases de datos. No has pasado del libro de CJ Date para
enterarte que hace tiempo que ya existen las implementaciones.

"De vez en cuando" no es lo mismo que tener "cada vez" que preparar
manualmente cuando se requiera postear una consulta, como sugieres en tus
mensajes. En todo caso, la administración normal de un SGBD implica por
ejemplo, regenerar las estadísticas periódicamente, reconstruir o agregar
índices recomendados, recompilar los sp's, etc. etc. pero... esas no son
labores por las que debamos preocuparnos frecuentemente ni los
programadores
ni los DBA's.

O sea que tu maravilloso automatismo que ahorra una línea obliga al
DBA a recompilar los SP periódicamente.¡Menuda ventaja!

Te podría empezar a hablar de DTS, tareas programadas, planes de
mantenimiento, pero en fin, no sirve de nada insistir contigo.
Otro razonamiento mediocre que vuelve a confirmar tu completa ignorancia
sobre administración de SGBD's.

Otra vez igual. Puedes crear diferentes vistas externas de la base de
datos y enseñar una vista distinta a cada aplicación.

por supuesto y los sp's, como los views, permisos, etc. contribuyen a
eso.

Los SP son innecesarios para esto y he visto montones de casos en los
que se usan muy mal para intentar ocultar la vista relacional debajo
de una capa procedimental. El primer mensaje de este hilo tenía toda
la pinta de ser eso.

Puede ser, pero debes leer mejor.

Si, están horriblemente limitadas en la versión actual de SQL Server,
pero muchas de esas limitaciones se pueden superar con un poco de
imaginación.

Me encantaria ver tus ejemplos especificos sobre esa tan "imaginativa"
afirmación.

Por si no sabías, las vistas indexadas no surgieron en esta
versión. Tienen ya unos añitos de existencia.

Ya lo sabía, pero no se a que viene esto. Las vistas materializadas de
Oracle tienen muchos más y son más potentes.

Bueno el tema de tu migración a SQL Server y "la novedad" de las vistas
indexadas lo traíste tú a la discusión.

Te aviso cuando acabe el mio :)

Deberías. Pero te falta mucho por estudiar, no sobre la teoría de BD que la
tienes, sino sobre las implementaciones que ya existen en el mercado, sino
quieres que tu SGBD termine usándose mono-usuario.

1-Especifico: Generar la tabla de amortización de un préstamo.

Hombre, si no sabes hacer esto sin un SP entonces me explico muchas
cosas.

Yo la verdad que no sé. Aquí estamos para aprender y no me averguenza como
a otros. Me podrías dar un link o explicarme cómo se haría con una vista?
Me refiero amortización típica (método francés) por si estás entendiendo
otra cosa como tantas otras que has demostrado que desconoces.

2-Especifico: Calcular los balances de las cuentas a un nivel de
profundidad
específico (dada una relación reflexiva de la entidad "cuenta")

No se muy bien lo que quieres decir con la relación reflexiva de la
cuenta,

Bueno, yo hasta ahora te había estado adjudicando conocimientos de teoría
básica de bases de datos pero con eso te acabas de desenmascarar. No dejas
de decepcionarme por eso.
Debes irte mucho más primitivo todavía, a la teoría de conjuntos. Como te
gustan las wikipedias: http://es.wikipedia.org/wiki/Relaci...reflexiva.
De todos modos, te ayudo diciéndote que "quise decir" una relación de la
entidad "cuenta" con sí misma (eso es una relación reflexiva o recursiva).
Para la implementación específica citada, sería en una estructura de árbol
(una cuenta "puede ser" padre de otra). La entidad cuenta posee entonces un
atributo con la PK de otra cuenta que es su padre. Imagino que así lo
entiendes mejor no? Los movimientos (transacciones) se registran sólo a
las cuentas de los nodos de último nivel del árbol, es decir, a las cuentas
que no tienen hijas, también conocidas como "auxiliares".
A "nivel de profundidad" me refiero a una "vista" de los balances de cuentas
a un nivel de recorrido de los nodos del arbol. Ejemplo calcular los
balances a nivel tres, me debe ignorar las cuentas de nivel cuatro en
adelante (aunque sean estas las que lleven los movimientos).
Pero me daría curiosidad si es que en vez de hacer un SP de servidor para
esto prefieres hacer el procesamiento en la aplicación cliente (sería
tremenda barrabasada). Quizás eso es lo que tratas de decir desde el
principio y te estoy malinterpretando. Si es así, no hay que discutir.

Bueno no sigo, ya que terminaré enviándote una factura por la clasesita ;)

pero para calcular balances yo no necesito ningún SP.

De las cuentas auxiliares no, pero a un nivel de profundidad específico (y
hasta quizás a un rango de fechas), que fue lo que dije (no lo leiste bien,
algo típico en ti), me gustaría me enseñaras. Aqui estamos para aprender.

Para hacer un escandallo se echa de menos el operador de cierre
transitivo. Disponiendo de ese operador genérico (que podría ser un
SP) ya no necesitamos otros SP para eso.

Para el ejemplo que he citado, has dicho tremenda tontería y hasta te
contradices citando que "podría ser un SP". No era eso lo que criticabas en
este caso especifico?

3-Mas genericos: a) Por limitaciones del SGBD: como subconsultas que
requieran varios group by y haya que usar una tabla temporal o variable
tipo
table intermedia. Tambien los TOP tienen ciertas limitaciones en la
construcción de consultas y asi por estilo.
b) Por eficiencia para tablas voluminosas:
Donde
sea mas eficiente (por plan de ejecución), traer algún dato puntual de
una
tabla por su PK, y cargarlo a una variable para filtrar la(s) consulta(s)
posterior(es) y evitar seeks o scans innecesarios.

Excepciones y limitaciones del SGBD. Lo normal es que no hagan falta
los SP.

En la teoría de BD de los libros no.

c) Reutilización del código de SP's: Cuando
requiera llamarse un SP ya existente como entrada de otras consultas
... d) Tambien por eficiencia: Combinar
actualización y consulta en un sólo "viaje" al servidor. Yo tengo por ej.
SP's de actualización que luego de la lógica que actualiza, me devuelven
un
set con datos frutos de un select o de una llamada a otro SP o funcion.
Ahorra tiempo innecesario.
...
,,, y asi por el estilo.

Esto ya son chorradillas. Si quieres usar un SP en vez de una
multiconsulta en un caso determinado para ahorrar algún milisegundo
pues vale.

De chorradillas parece estar lleno tu cerebro. Tú eres sin duda de los que
repite un mismo bloque de código, aunque sea extenso, en un trigger por
"evitar un SP" o una función de usuario de servidor. Deben sur muuuuy
fáciles de mantener tus aplicaciones de bases de datos :).

Esos serian casos donde se podrian "necesitar". Pero en mi caso por las
multiples ventajas expuestas los uso tambien donde no solo se "necesiten"
sino tambien donde sean altamentes favorecedores de la encapsulación, de
claridad del código, de la seguridad y de la optimización del desempeño.

Pero el código declarativo lo es más.

Nadie está discutiendo eso. Pero el alcance del concepto "declarativo"
también es dependiente de la implementación.

En mi respuesta yo me basé en esta frase que escribiste: "¿Que diferencia
hay entre "amarrarse" a tablas que a SP?"

Depende de como sean los SP. Si se mantiene la propiedad del cierre
relacional entonces da igual.

Mira yo uso vistas también, muchas y frecuentemente.
Nadie dice que no se pueda hacer con vistas. Solo cito (lo repito) como
una
ventaja agregada de un SP la facilidad para la seguridad y tambien la
mayor
fortaleza a la inyección de código. Mantener los permisos a una tabla (o
a
una vista, ya que insistes) requiere mayor trabajo que a un SP que haga lo
mismo (ej. devolver una lista de clientes en mora), ya que los SPs en si
mismos no son objetos actualizables como las tablas y vistas. Sobre la
inyección de código normalmente los front-ends controlan mejor las
llamadas
a SPs (suele haber instrucciones separadas para ellos) que a simples
consultas abiertas aunque estas sean "preparadas". Si estas no son
ventajas
bueno allá tu que no lo quieras ver así en tu inútil esfuerzo por
sustentar
tus ideas.

Son pijotadas que no cambian la regla general.

Teoría e implementación son cosas distintas. Pijotadas son todas las
tonterías que has dicho. Es una desverguenza de tu parte andar opinando de
cosas que no conoces. A mi nadie me ve opinando sobre temas que desconozco.

No estoy diciendo eso. Hasta sin preparar, si repites la misma consulta
de
forma consecutiva, el servidor normalmente te guarda el plan en caché.
Sólo
que con los SP's no hay que hacerlo manualmente. Lo hacen automáticamente
en
la primera ejecuciojn y ademas persisten al cierre de la conexión de los
clientes, no se guardan solo en el cache por un tiempo. Eso es para mi
una
grandísima ventaja sobre todo en consultas complejas, frecuentes y
concurrentes.

Lo que dices es absurdo. El plan de una consulta frecuente estará casi
siempre en la caché, así que no se gana nada.

Es que la ventaja no es sólo para las consultas frecuentes. También lo es
para las complejas aunque no sean tan frecuentes, debido a que no sólo es un
usuario que usa una base de datos en un instante cualquiera.

Pero te aclaro que la pregunta te la hice porque me dio la impresion que
cuando hablabamos de pre-compilacion no te referias al plan de ejecucion y
costo de la consulta. De hecho nunca mencionaste el termino propiamente.
Por
eso pense que no conocias ese tema.

Ah, vale, entonces aclarado.

La verdad que no parece. O al menos no fuiste el encargado de implementar
esas aplicaciones.

Pues si fui yo. Pero teníamos un montón de servidores de datos en
paralelo con doble procesador funcionando 24 horas, así que no nos
teníamos que preocupar mucho por ese tipo de pijotadas de si el plan
de ejecución era persistente o no.

Bueno pues te portaste como se portan los programadores mediocres. Hay que
documentarse primero para hacer implementaciones de esa envergadura.

No te lleves de todo lo que lees.


Las aplicaciones de bases de datos (y eso es teoría básica de desarrollo en
2 capas), el front-end debe desacoplarse lo más que se pueda del back-end.
Para ello el programador de la interfaz no tiene por qué conocer DML ni
DDL. Igual el DBA y el programador de T-SQL tampoco tienen por qué conocer
sobre la capa de presentación y pueden ignorar perfectamente el lenguaje en
que esté desarrollada la interfaz. En algunas empresas grandes, pueden
incluso contratar dos equipos distintos para cada capa. Peor aún puedes ir
a una empresa a instalar un sistema y encontrarte allí ya con los SP's y las
vistas que comparten con otras aplicaciones (otros front-ends). Hay que
aprender a separar los conceptos si se quiere desarrollar aplicaciones que
sean económicas de mantener y escalar en el tiempo y sobre todo si quieres
"vivir" de esto por varios años.
La mezcla de conceptos es lo que hace a la gente fracasar en los grandes
desarrollos.



"Carmelo J. Morales Muñoz" wrote in message
news:

eso es cierto, el sql standard suele ser idéntico, los store proc ya es
otra cosa, solo he visto algo de oracle y sqlserver, y la verdad es que
estás en lo cierto, ahora te entiendo.