Sobre Serialización

On Mon, 14 Feb 2005 08:29:48 -0800, "Carlos"
wrote:

Hola,

Digamos, que tengo una clase Empleado, que está
relacionada con una tabla de la base de datos, TEmpleado.

Pues empezamos mal, por que clases y tablas no tienen nada que ver. No
se deben de asociar clases y tablas. Lo que si se puede hacer es
asociar clases y dominios, que son basicamente lo mismo.

Con SQL Server 2005 podemos crear nuevos dominios usando clases C#.

Según lo poco que he leido, se puede serializar una
instancia (objeto) de la clase Empleado en una tabla de
Base de datos.

Si, se puede grabar un registro en formato binario en una tabla de una
base de datos, pero eso no quiere decir que sea buena idea.

Bien, también existe la posibilidad a partir de un objeto
Empleado, insertar/modificar/eliminar un registro de la
tabla TEmpleado a partir de los valores de las
propiedades de la clase Empleado.

Si, pero también es una mala idea por lo que he dicho antes.

Las cuestiones serían: qué utilidades o potencialidades
tiene usar la serialización en estos casos ?

No necesitas usarla. SQL Server 2005 se encarga de hacerlo
automáticamente.

Lo único que tienes que hacer es cumplir los requisitos de los UDTs de
SQL Server 2005 (declarar atributos e implementar interfaces).

En cuanto al rendimiento,q ué es más rápido:
serializar un objeto de una clase en base de datos, y
luego el proceso inverso, deserializar un objeto (de una
clase) de base de datos en una instancia de la clase,

El equivalente a un objeto dentro de una base de datos es un valor de
una fila de una tabla.

Por ejemplo si tenemos un objeto "Teléfono" podemos guardarlo en una
columna de una fila de la tabla "Empleados".

Si queremos guardar un objeto más complejo como por ejemplo una figura
geométrica podemos extender el sistema de tipos de SQL Server 2005

Aquí tienes unos enlaces que dicen como se hace:

http://msdn.microsoft.com/msdnmag/i...TsinYukon/
http://www.devx.com/dotnet/Article/22644
http://weblogs.asp.net/angelsb/arch...97785.aspx

Saludos, espero que no esté confuso mi mensaje, aun sigo
confuso con estos temas.

Es bastante fácil estar confuso sobre estos temas. La mayoría de la
gente que escribe sobre bases de datos no tiene ni idea.


Saludos

Voy a puntualizar:

- Sé que una cosa es una tabla Empleado y otra cosa la
clase Empleado. Pero para mi aplicación el concepto es el
mismo, utilizo la clase Empleado para representar en C# un
empleado en mi aplicación y la tabla Empleado para
persistencia de los datos de ese empleado.
Para mim aplicación existe una correspondencia campos de
la tabla Empleado con propiedades clase Empleado (similar
a clase Dataset de una tabla que se puede obtener mediante
utilidad de VS.NET). Es una especie de ORM para mi,
aunque conceptualmente no sea así, en la práctica, para mi
es útil y funcional.

- No utilizo SQL Server 2005, sino SQL Server 2000.
Desgraciadamente, o afortunadamente, no puedo utilizar
esas características.
Además, es posible que en el futuro tampoco pueda
utilizarlas, puede darse el caso que utilice Oracle,
MySQL, ODBC, etcétera.
Por ello, quería aclarar estos conceptos.

- Siempre he pensado que la confusión se aclararía en
estos foros, leyendo documentación de Internet, etcétera.
Desgraciadamente no puedo distinguir qué personas que
escriben de base de datos tienen idea y cuáles no.

On Mon, 14 Feb 2005 08:29:48 -0800, "Carlos"
wrote:

Hola,

Digamos, que tengo una clase Empleado, que está
relacionada con una tabla de la base de datos, TEmpleado.

Pues empezamos mal, por que clases y tablas no tienen

nada que ver. No

se deben de asociar clases y tablas. Lo que si se puede

hacer es

asociar clases y dominios, que son basicamente lo mismo.

Con SQL Server 2005 podemos crear nuevos dominios usando

clases C#.

Según lo poco que he leido, se puede serializar una
instancia (objeto) de la clase Empleado en una tabla de
Base de datos.

Si, se puede grabar un registro en formato binario en una

tabla de una

base de datos, pero eso no quiere decir que sea buena

idea.

Bien, también existe la posibilidad a partir de un

objeto

Empleado, insertar/modificar/eliminar un registro de la
tabla TEmpleado a partir de los valores de las
propiedades de la clase Empleado.

Si, pero también es una mala idea por lo que he dicho

antes.

Las cuestiones serían: qué utilidades o potencialidades
tiene usar la serialización en estos casos ?

No necesitas usarla. SQL Server 2005 se encarga de hacerlo
automáticamente.

Lo único que tienes que hacer es cumplir los requisitos

de los UDTs de

SQL Server 2005 (declarar atributos e implementar

interfaces).

En cuanto al rendimiento,q ué es más rápido:
serializar un objeto de una clase en base de datos, y
luego el proceso inverso, deserializar un objeto (de una
clase) de base de datos en una instancia de la clase,

El equivalente a un objeto dentro de una base de datos es

un valor de

una fila de una tabla.

Por ejemplo si tenemos un objeto "Teléfono" podemos

guardarlo en una

columna de una fila de la tabla "Empleados".

Si queremos guardar un objeto más complejo como por

ejemplo una figura

geométrica podemos extender el sistema de tipos de SQL

Server 2005

Aquí tienes unos enlaces que dicen como se hace:

http://msdn.microsoft.com/msdnmag/i...DTsinYukon

/

http://www.devx.com/dotnet/Article/22644
http://weblogs.asp.net/angelsb/arch...6/197785.a

spx

Saludos, espero que no esté confuso mi mensaje, aun sigo
confuso con estos temas.

Es bastante fácil estar confuso sobre estos temas. La

mayoría de la

gente que escribe sobre bases de datos no tiene ni idea.


Saludos

.

On Mon, 14 Feb 2005 12:21:50 -0800,
wrote:

Voy a puntualizar:

- Sé que una cosa es una tabla Empleado y otra cosa la
clase Empleado. Pero para mi aplicación el concepto es el
mismo, utilizo la clase Empleado para representar en C# un
empleado en mi aplicación y la tabla Empleado para
persistencia de los datos de ese empleado.

Pues muy mal hecho. Los Sistemas de Gestión de Bases de Datos se
utilizan para muchas más cosas además de la persistencia. Eso te lo
explican en los primeros capítulos de cualquier texto serio de
introducción a los sistemas de bases de datos.

Los SGBD se utilizan para gestionar la información, y si la base de
datos tiene una tabla Empleado entonces la aplicación no necesita
ninguna clase Empleado, que solo serviría para complicar las cosas. Es
más, los SGBD se crearon entre otras cosas para eliminar la necesidad
de ese tipo de clases. Es una parte de todo el trabajo que nos ahorran
los SGBD.

Lo que tienes que hacer es mapear la tabla Empleado a la interfaz de
usuario usando algo del estilo de ADO.NET, aunque ADO.NET tampoco me
gusta un pelo.

Repito que tablas y clases son completamente diferentes. Eso que dices
de que para tu aplicación el concepto es el mismo no tiene sentido.

Para mim aplicación existe una correspondencia campos de
la tabla Empleado con propiedades clase Empleado

Entonces tu aplicación está mal diseñada.

No hay correspondencia entre los atributos de una tupla y las
propiedades de una clase.

(similar
a clase Dataset de una tabla que se puede obtener mediante
utilidad de VS.NET).

No, no es similar. En el caso de un DataTable de ADO.NET la
correspondencia se da entre una variable de tipo DataTable y una
tabla. En este caso estamos mapeando entre dos variables y no entre un
tipo y una variable. En este caso la correspondencia es en principio
aceptable.

Es una especie de ORM para mi,

El llamado Object Relational Mapping es un concepto totalmente
equivocado del que conviene apartarse lo más posible.

aunque conceptualmente no sea así, en la práctica, para mi
es útil y funcional.

Según con que lo compares. Si lo comparas con una aplicación bien
realizada la diferencia es brutal, pero si es la única forma de
trabajar que conoces pues entonces es normal que la encuentres útil.

No es que hacer las cosas así no funcione, sino que hay formas
infinitamente mejores de hacerlo.

- No utilizo SQL Server 2005, sino SQL Server 2000.
Desgraciadamente, o afortunadamente, no puedo utilizar
esas características.

Bueno, tendrías que preguntarte si realmente las necesitas. Las bases
de datos de gestión raramente necesitan tipos definidos por el usuario
(UDTes). Casi todo lo puedes resolver con los tipos predefinidos de
SQL: numeros, fechas, cadenas, etc.

Las entidades como Empleados se deben de modelar como tablas y no como
tipos escalares, y las propiedades de entidades como Empleados suelen
encajar bien con los tipos predefinidos de SQL.

Por esta razón se ha tardado tanto en incluir la posibilidad de crear
nuevos tipos en los SGBD comerciales: no hacen mucha falta para las
aplicaciones de gestión. Estas características son mucho más
necesarias para sistemas GIS o CAD.

Además, es posible que en el futuro tampoco pueda
utilizarlas, puede darse el caso que utilice Oracle,

Oracle tiene características parecidas desde mucho antes que SQL
Server.

MySQL, ODBC, etcétera.

MySQL es un SGBD muy pobre. Y eso las últimas versiones. A las
versiones anteriores ni si quiera se las podía considerar como un
SGBD. Yo no recomendaría MySQL para un sistema de gestión serio por
muy barato que sea.

- Siempre he pensado que la confusión se aclararía en
estos foros, leyendo documentación de Internet, etcétera.

Pues desgraciadamente eso no suele ocurrir, y menos en el mundo de las
bases de datos.

Además esto no es un tema de documentación de productos comerciales,
es un tema de fundamentos de la informática. Sobre eso no suele haber
mucho material de calidad disponible en la red. La mayoría de la
información que hay en la red está escrita por gente que está
intentando venderte sus productos.

Desgraciadamente no puedo distinguir qué personas que
escriben de base de datos tienen idea y cuáles no.

Pues te doy enlaces sobre la gente que más sabe sobre esto para que
puedas comparar:

www.dbdebunk.com

El mejor libro con diferencia sobre introducción a la teoría de bases
de datos que hay en el mercado es este:

http://www.agapea.com/Introduccion-...11521i.htm

Es una lectura imprescindible para cualquiera que quiera desarrollar
sistemas de gestión de forma seria.


Saludos

Solo una pregunta para confirmar si me estoy enterando de lo que decis, tu
sugieres, que aunque se use POO, la base de datos tenga un diseño
relacional en lugar de ser Orientado a Objetos.

¿es asi, o lo he entendido mal?

Gracias

On Tue, 15 Feb 2005 03:27:27 +0100, Moi
wrote:

Solo una pregunta para confirmar si me estoy enterando de lo que decis, tu
sugieres, que aunque se use POO, la base de datos tenga un diseño
relacional en lugar de ser Orientado a Objetos.

Si, por supuesto.

La OO es solo para el nivel de aplicación. Es decir para la
presentación de datos y comunicación con los usuarios.

La OO no tiene aplicación a las bases de datos. Lo que normalmente se
suele conocer como bases de datos OO no son más que obsoletas bases de
datos de Red reinventadas.

Por otra parte las bases de datos XML son una pobre reinvención del no
menos obsoleto Modelo Jerárquico.

Las llamadas bases de datos OO fueron una moda pasajera de principios
de los 90 que fracasó estrepitosamente por que heredaba todas las
desventajas del Modelo de Red. Actualmente casi nadie las usa. Lo más
gracioso es que hay bastantes programadores que todavía creen que son
el futuro :)

Con las bases de datos XML está pasando más o menos lo mismo, pero una
década después. Estaban de moda hace unos pocos años y ahora su uso ha
caido en picado.


Saludos