DataSet vs Entidades personalizadas

Hola a todos. Perdonad que me entrometa en la conversación pero es que me
parece interesantísima.

Creo que me encuentro en la misma situación, más o menos, que Erick y quiero
remarcar un par de frases de Alfredo:

(...) muchas formas disparatadas de intentar resolver el problema.

(...) trabajo es enorme para no ganar nada.

(...) No es suficiente poner la lógica de negocio en una capa separada pero
dentro de las aplicaciones (sigue siendo un sistema monolítico), la lógica
de negocio hay que sacarla fuera de las aplicaciones. Esto es algo muy
elemental.

(...) Para crear un Sistema de Información además de programadores se
necesitan expertos en bases de datos, pero desgraciadamente en la práctica
muchas veces solo hay programadores, y así pasa lo que pasa.

Creo que Alfredo tiene razón en muchas cosas. Me considero 'programador' y
más bien flojo en los SGBD. Por lo tanto intento 'resolver mis problemas' de
la única forma que se: con la programación . Efectivamente es un trabajo
enorme y me gustaría que me convencieses de que no sirve para nada y de que
se puede separar del todo la lógica de negocio de la aplicación .

¿Tienes ejemplos, links, etcétera de cómo resolver estos problemas en el
SGDB? ¿El libro que recomiendas es completo a nivel de ejemplos y de
aplicaciones reales, o más bien solo explica conceptos teóricos como
relaciones, triggers, vistas, etcétera? (Es que he visto el índice y no me
ha dado muy buena pinta ya que sé, o creo saber, como montar un buen sistema
relacional, pero después no se como resolver los 'problemas' que me surgen
al diseñar mi aplicación y que ahora soluciono simplemente con programación)

¿Qué pasa cuando nuestras soluciones se limitan a una base de datos como
MySql y no a un SGBD como Oracle o SqlServer?

Bueno, en definitiva, siempre he utilizado la POO para resolver 'mis
problemas' pero creo que hay algo más. ¿Alguien puede señalarme el camino a
seguir para resolver estas dudas?

(Esto ha quedado un poco místico ;-P)

Saludos.
Ernesto Lores.

On Tue, 12 Jul 2005 10:06:03 +0200, "e-lores"
wrote:

Hola,

Hola a todos. Perdonad que me entrometa en la conversación

Aquí nadie se entromete, todo el mundo puede decir lo que piensa.

Creo que Alfredo tiene razón en muchas cosas. Me considero 'programador' y
más bien flojo en los SGBD. Por lo tanto intento 'resolver mis problemas' de
la única forma que se: con la programación .

Bueno, siendo un poco más precisos querrás decir que intentas resolver
tus problemas con la programación imperativa procedimental, pero
existen otras formas de programación como la lógica y la declarativa.
Los SGBD también se programan. Crear una tabla o una vista también es
programación.

¿Tienes ejemplos, links, etcétera de cómo resolver estos problemas en el
SGDB?

Los tengo pero desperdigados, pero si me pones un ejemplo te puedo
decir como se resolvería en el SGBD.

¿El libro que recomiendas es completo a nivel de ejemplos y de
aplicaciones reales, o más bien solo explica conceptos teóricos como
relaciones, triggers, vistas, etcétera?

Es un libro teórico. Tiene muchos ejemplos pero son ejemplos sencillos
para explicar los conceptos.

(Es que he visto el índice y no me
ha dado muy buena pinta ya que sé, o creo saber, como montar un buen sistema
relacional, pero después no se como resolver los 'problemas' que me surgen
al diseñar mi aplicación y que ahora soluciono simplemente con programación)

Pues a mi esto me parece una contradicción evidente. Si no sabes como
resolver los problemas entonces no sabes como montar un buen sistema
relacional.

Por otra parte es MUY dificil conocer bien los sistemas de bases de
datos relacionales sin haber leido ese libro. Es el mejor con
diferencia y hay muchas cosas que no se explican bien en otros libros.
Es considerado como la referencia estandar en la materia y es
sencillamente imprescindible.

¿Qué pasa cuando nuestras soluciones se limitan a una base de datos como
MySql y no a un SGBD como Oracle o SqlServer?

Las últimas versiones de MySQL ya se pueden considerar como un SGBD,
aunque sigue siendo bastante malo.

Pero si no usas un SGBD pues está claro que no te va a quedar más
remedio que implementar la lógica de negocio en las aplicaciones. Por
eso hay que usar los SGBD.

Bueno, en definitiva, siempre he utilizado la POO para resolver 'mis
problemas' pero creo que hay algo más. ¿Alguien puede señalarme el camino a
seguir para resolver estas dudas?

Ese libro es un punto de partida muy bueno. Yo no querría trabajar con
alguien que no lo hubiese leido.

Aquí tienes un montón de información y de enlaces:

www.dbdebunk.com


Saludos