Trabajar con metadatos


#1

Buenas,
en breve comenzaré a desarrollar una
aplicación donde necesitaré trabajar con metadatos y no sé
muy bien como afrontarlo usando ruby on rails. El
caso que el usuario deberá poder generar
documentos a partir de formularios que tendrán un
número indefinido de elementos y cuyos elementos
podrán ser de distintos tipos(listas
desplegables, campos de texto, o una
composición de ambos). El problema no se me plantea a la hora
de crear los distintos formularios en sí, si no a
la hora de tratar de guardar el documento con los
valores seleccionados en el formulario ya que no
puedo meterlos en la misma tabla ya que los
documentos podrían tener estructuras totalmente distintas entre
sí.La solución que se me había ocurrido era la de
guardar en la tabla de la base de datos lo que sí
que sea común a todos los
documentos(identificador, fecha de creación,
autor, etc.) y guardar los datos variables dentro
de un fichero xml o yml ya que siempre me
resultará más flexible que estar creando y
borrando tablas y columnas de la bd. Entonces
cuando vaya a recuperar un documento de la base
de datos, lo que haría sería leer el fichero xml
o yml en cuestión y generar los atributos de
manera dinámica en en base al contenido.
¿Cómo veis este planteamiento? ¿Alguna solución más sencilla?
Muchas gracias

Saludos

/**


#2

Hola!

Vas a necesitar buscar informacion sobre los datos xml o yml que
guardes??
date cuenta que guardandolos así te va a ser mucho más dificultoso hacer
búsquedas.

Un saludo
Roberto M. Oliva

El vie, 27-04-2007 a las 17:35 +0200, Borja Martín escribió:


#3

No, en principio no voy a necesitar realizar búsquedas sobre los campos
almacenados fuera de la base de datos y por eso me pareció bien la idea
que propuse y en caso de necesitar realizar búsquedas, utilizaría algún
sistema de indexación tipo Ferret.

Saludos

On Fri, 2007-04-27 at 18:01 +0200, Roberto M. Oliva wrote:

de ambos). El problema no se me plantea a la hora
de un fichero xml o yml ya que siempre me


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es

/**


#4

Muchas gracias por la respuesta. Tendré en cuenta todo lo que
comentas(no había caido por ejemplo en guardar toda la info variable
serializada en un sólo campo)

Saludos.

On Fri, 2007-04-27 at 18:19 +0200, javier ramirez wrote:

parecido entender que en tu caso el problema es que hay n campos de un
rápido, es estándar, funciona bien, te permite hacer queries y hay
claro no es problema, lo más rápido es delegar en AR para que serialize
él directamente y te olvidas. Si no, puedes hacer un to_xml o un to_yaml
y a la vuelta recomponer la información desde la cadena serializada.

Saludos,

javier ramirez


/**


#5

Hola!

Tienes otra posibilidad que he utilizado alguna vez que he requerido
montar
tablas enormes, de muchos campos y es crear una base de datos dentro de
la
base de datos. Me explico:

Defines una tabla “clase” que contenga la definicion del objeto a
guardar
(id, nombre, descripcion), otra tabla, denominada atributo que contenga
la
definicion de los campos que pueda tener cada tipo de objeto (id,
clase_id,
nombre, tipo_atributo, valor_por_defecto, etc). Y luego una tabla que
contemple cada valor de cada instancia de un objeto creado con la
estructura
de la clase definida, esta tabla tendria la sigueinte estructura: id,
clase_id, atributo_id, valor). De esta forma, para crear un tipo nuevo
de
dato, te bastaria con insertar un registro en la tabla de clases y luego
una
lista de los atributos que pueden tener los objetos de dicha clase.
Esto que, es complejillo de implementar, te permite varias cosas: tener
tablas de datos con registros inmensos, no estaría limitado por el numero
de
columnas que te permite la BD y te generarían los formularios de entrada
de
datos automáticamente. Al tener definido en la base de datos la estructura
de los datos, es muy sencillo generar un interfaz dinamico que se adapte
al
tipo de dato que se esta pidiendo. Tambien tiene la ventaja de que es
tremendamente sencillo actualizar la aplicación si se modifica la
estructura
de un dato: Simplemente modificando la tabla de atributos de la BD, se
modifica todo el interfaz de la aplicación. La gran pega que yo le he
encontrado a este sistema es el apartado de busquedas, que tiene que
hacer
una consulta mas, lo cual no es muy problemático, dependiendo de las
necesidades de rendimiento que tengas y que las consultas tabulares son
bastante complicadas.

Este sistema es el que utilizan tanto el CCK de Drupal o el Sharepoint
de
M$. Veras que con cualquiera de las dos herramientas tienes un interfaz
para
generar los tipos de datos que quieras introducir. Sharepoint implementa
un
sistema de base de datos, que esta en un camino medio entre toda la
flexibilidad que he expuesto antes y la velocidad de busqueda y
tratamiento
tabular de los datos y es que solo tiene una tabla de clases, no de
atributos y los campos de dicha clase incluyen los atributos de tal
manera
que tiene, por ejemplo, 5 campos para albergar cada tipo de dato. Por
ejemplo, la estructura de la tabla seria asi: id, clase, int1, int2,
int3,
int4, int5, date1, date2, date3, date4, date5,…, bool1, bool2, bool3,
bool4, bool5, etc. Esto te permite tambien definir tipos de contenido
que
sean muy flexible, siempre que no sobrepasen el limite de 5 datos de un
mismo tipo dentro de su estructura. Digamos que no es tan flexible como
la
propuesta anterior, pero es lo suficientemente flexible para cubrir un
gran
porcentaje de requerimientos sin la penalizacion de rendimiento que la
otra
propuesta presenta.

Despues de este rollo contandote aproximaciones a sistemas de metadatos,
mi
gran pregunta es si esto en Rails se puede implementar y me temo que
Rails
esta pensado para cosas mucho mas simples. Habria que adaptar tanto el
interfaz y el modelo de la aplicación que, a priori, puede suponer una
tarea
mucho mas grande que la ventaja que supone utilizar Rails… De todas
formas, es solo una impresión, habria que probarlo para verlo. A lo mejor,
la aproximacion de Sahrepoint no es tan descabellada montarla en Rails.

Espero que no te hayas aburrido, me impresionaria que hubieses llegado a
leer hasta aquí… Jejeje.
Espero sobre todo que te ayude

Un saludo
Roberto M. Oliva

-----Mensaje original-----
De: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] En nombre de Borja
MartínEnviado el: viernes, 27 de abril de 2007 20:39
Para: La lista sobre Ruby On Rails (rubyonrails.com) en castellano
Asunto: Re: [Ror-es] Trabajar con metadatos

Muchas gracias por la respuesta. Tendré en cuenta todo lo que comentas(no
había caido por ejemplo en guardar toda la info variable serializada en un
sólo campo)

Saludos.

On Fri, 2007-04-27 at 18:19 +0200, javier ramirez wrote:

Hola

caso que el usuario deberá poder generar documentos a partir de
formularios que tendrán un número indefinido de elementos y cuyos
elementos podrán ser de distintos tipos(listas

de un fichero xml o yml ya que siempre me resultará más flexible que
estar creando y borrando tablas y columnas de la bd.
padre con los campos comunes y n en esta tabla cada uno con su campo
campos, es serializar directamente la estructura y guardarla en una
columna tipo clob en la misma tabla. Así tienes por un lado la
cabecera común separada en campos buscables/indexables y por otro lado
la estructura serializada en la misma tabla, y te olvidas de
sincronizar con el filesystem.

para serializar tienes varias opciones. Si que los datos no se vean en
claro no es problema, lo más rápido es delegar en AR para que
serialize él directamente y te olvidas. Si no, puedes hacer un to_xml
o un to_yaml y a la vuelta recomponer la información desde la cadena
serializada.

Saludos,

javier ramirez


/**


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es


#6

Hola

caso que el usuario deberá poder generar documentos a partir de formularios que tendrán un número indefinido de elementos y cuyos elementos podrán ser de distintos tipos(listas

de un fichero xml o yml ya que siempre me resultará más flexible que estar creando y borrando tablas y columnas de la bd.
si tienes claro que la estructura es realmente dispar, no te queda mucha
más opción que lo que comentas: separar por un lado la parte común y por
otro la parte que varía.

Ahora bien, si vas a tener n tipos de documentos, lo mismo puedes montar
una estructura de db que te lo soporte directamente. Por ejemplo, me ha
parecido entender que en tu caso el problema es que hay n campos de un
tipo u otro. Siempre podrías sacar una tabla de campos que tuviese el
tipo de campo y su nombre y que estuviese unida con acts_as_list al
registro padre. De esa forma tendrías un registro padre con los campos
comunes y n en esta tabla cada uno con su campo position que te indica
nombre y tipo.

Si lo que tienes es una estructura anidada más compleja y no te vale esa
solución y finalmente te inclinas por la parte de xml, que sepas que
tienes varias opciones. Una opción es usar una base de datos que soporte
xml de forma nativa, como db2, y hacer las queries con XQUERY. Es
rápido, es estándar, funciona bien, te permite hacer queries y hay
driver para rails bastante bien soportado.

una opción más simple, siempre que no necesites búsqueda por esos
campos, es serializar directamente la estructura y guardarla en una
columna tipo clob en la misma tabla. Así tienes por un lado la cabecera
común separada en campos buscables/indexables y por otro lado la
estructura serializada en la misma tabla, y te olvidas de sincronizar
con el filesystem.

para serializar tienes varias opciones. Si que los datos no se vean en
claro no es problema, lo más rápido es delegar en AR para que serialize
él directamente y te olvidas. Si no, puedes hacer un to_xml o un to_yaml
y a la vuelta recomponer la información desde la cadena serializada.

Saludos,

javier ramirez

Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!