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: [email protected]
[mailto:[email protected]] 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
[email protected]