SimpleDB on Rails

En Euruko, Fernando Guillén nos hablaba de una aplicación que habia
creado con una base de datos muy simple y muy desnormalizada. A quien
se le ocurre guardar todas las referencias de un producto dentro del
mismo producto, con sus tallas, colores i otras carácteristicas.
Despues de intentar explicarle como lo podria haber hecho, de una
manera mas “normalizada”.

Finalmente nos la enseño. Y flipé, nunca se me hubiera ocurrido
realizar tal cosa, de hecho, lo hubiera llamado chapuza.

Hoy David lo linka en “Riding Rails”. Un ejemplo de como usar SimpleDB
con ActiveResource.

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1242

Me costaba ver el uso de una base de datos como SimpleDB, y hoy
recordando el diseño de Fernando, he unido cabos. SimpleDB es la bomba.

Un saludo,

Francesc

2008/4/1 Francesc E. [email protected]:

Finalmente nos la enseño. Y flipé, nunca se me hubiera ocurrido
realizar tal cosa, de hecho, lo hubiera llamado chapuza.

Si no me equivoco Fernando es miembro de la lista también. Fernando,
¿es posible que nos hables un poco al respecto?

2008/4/2, Federico B. [email protected]:

Finalmente nos la enseño. Y flipé, nunca se me hubiera ocurrido
realizar tal cosa, de hecho, lo hubiera llamado chapuza.

Al ejemplo de SimpleDB le veo el mismo problema que comentábamos con
el caso de Fernando: ¿permite obtener un listado ordenado? Ojeando por
encima la doc de SimpleDB no encuentro ningún ejemplo sobre esto. En
caso de no necesitar esta funcionalidad y no tener un gran número de
registros sí puede resultar útil.

(Quiero añadir que pese a nuestra reticencia inicial, el código de
Fernando se ajustaba perfectamente a las necesidades de su cliente:
que nadie piense que se trataba de una “chapuza”, simplemente se
alejaba del modelado entidad-relación habitual).

He dicho “lo hubiera llamado chapuza” … y hubiera quedado más claro
que no lo es. Es una denormalización de la base de datos que como bien
dices se alejaba de la entidad relación habitual, y para su proyecto
iba perfecto.

He encontrado un ejemplo en la documentación de Amazon SimpleDB [1],
sección Detailed Description, y creo que se parece bastante a la
denormalización de Fernando.

Si que se pueden obtener listados ordenados, pero teniendo en cuenta
que la base de datos esta denormalizada, y que por tanto tenemos las
“relaciones” dentro del mismo modelo se ha de intentar que las claves
de búsqueda principales esten bien diseñadas. Que alguien me corrija
si me equivoco. Un aproximación de como puede ser la base de datos
es …

Producto
- nombre
- modelos (Aquí es donde se denormalizaba ya que incluia
todos los modelos separandolos con un cambio de linea.)

“Think of these terms as analogous to concepts in a traditional
spreadsheet table. For example, take the details of a product catalog
shown in the table below and consider how they would be represented in
Amazon SimpleDB. The whole table/catalog would be your domain named
“clothing.” Individual products would be rows in the table or items
in your domain. The characteristics of items would be described by
column headers (attributes). Values are in individual cells. Now
consider the items below - a sweater, a dress shirt and a pair of
shoes - are new products you would like to add to your domain.”

Super interesante para hacer pruebas con ActiveResource.

Un saludo,

Francesc

[1] http://www.amazon.com/b?ie=UTF8&node=342335011

El 2/04/08, David C. [email protected]
escribió:> [1] http://incubator.apache.org/couchdb
Aaah, entendido entonces: no es un bug sino una feature :smiley: Gracias
David!

2008/4/2 Raul M. [email protected]:

2008/4/2, Federico B. [email protected]:

Finalmente nos la enseño. Y flipé, nunca se me hubiera ocurrido
realizar tal cosa, de hecho, lo hubiera llamado chapuza.

Al ejemplo de SimpleDB le veo el mismo problema que comentábamos con
el caso de Fernando: ¿permite obtener un listado ordenado? Ojeando por
encima la doc de SimpleDB no encuentro ningún ejemplo sobre esto. En
caso de no necesitar esta funcionalidad y no tener un gran número de
registros sí puede resultar útil.

No he trabajado con SimpleDB pero si con CouchDB[1], que creo que fue la
que
empezó con la carrera esta de las bases de datos documentales. Por lo
que se
de CouchDB, este tipo de bases de datos estan optimizadas para trabajar
con
vistas ordenadas. Lo que se suele hacer en CouchDB para ordenar un
documento
como tu quieres es hacer una vista de ese documento y añadir al índice
los
campos por los que quieres ordenar. Por ejemplo, si tengo un documento
con
los campos id, name y surname y quiero ordenar por surname:

map(doc.surname, doc);

[1] http://incubator.apache.org/couchdb

Gracias Francesc y Raul por dejar claro que no os parecí un chapuzas :wink:

Aunque en realidad mi intención se acercaba mucho a ser un ‘chapuzas’
consciente.

Atención que va un rollo largo…

Una de las (muchas) cosas que me ha llamado la atención de Rails es su
escasa paranoia por el diseño académico estricto en post de una
máságil, simple y ligera (‘chapucera’) manera de programar:

  • campos autoincrementales
  • motores de persistencia pesados pero más sencillos de usar.
  • desnormalización sin pudor: por ejemplo en la definición de tablas
    polimórficas.
  • convención frente a
    optimización* … cosas que seguiré descubriendo.

Fué otro pequeño destello, hacía tiempo que notaba que me esforzaba
demasiado en hacer las ‘cosas bien’:

  • modelos estrictamente normalizados aunque esto implicara
    máslentitud en las búsquedas y más complejidad de tablas.

  • capas estrictamente impermeables pensando en grandes refactors que
    luego nunca llegaban.

Mi primera aproximación Rails ha sido una tiendita online para unos
amigos ( http://tienda.holaporque.com ). Quería seguir el patrón KISS
incluso en el diseño del código y el modelo. Al final me ha quedado un
MODELO DE 2 TABLAS :stuck_out_tongue:

Quería centrarme en las necesidades básicas del ‘cliente’, no
queríahacer algo configurable.

Entonces me dí cuenta que las necesidades del cliente eran un puto
follón:* Atributos con mucha casuística: modelo, talla, color, variante
chico-chica.

  • Control de Stock por modelo, talla, color, variante chico-chica
  • Precio individual por modelo, talla, color, variante chico-chica
  • Vender otras cosas que no sólo fueran camisetas: CDs, obra gráfica.
    Con atributos personales.
  • Filtrar por categorías: Vestidos, Camisetas, CDS, Obra gráfica
  • Filtrar por variante: chico, chica.
  • Mostrar precio máximo y mínimo.
  • Varias fotos y varios tamaños.
  • El usuario debe poder elegir para cada camiseta: modelo, talla,
    color, variante chico-chica y cantidad teniendo en cuenta que no
    siempre iba a haber stock de toda la combinatoria posible.

Me empecé a poner nervioso y ví que me estaba metiendo en otro
lío-aplicación-de gestión. Que iba a tener un montón de tablas,
relaciones super malabarísticas, un modelo super pesado, lógica de
vista liosa, …

Entonces tomé la decisión de ni siquiera cubrir todas las necesidades
del ‘cliente’ de manera explícita y optimizada sino proporcionar un
conjunto de funciones muy genéricas que el ‘cliente’ pudiera usar
para, con un poco de malabarismo, alcanzar todas sus espectativas.

Por ejemplo:

  • No hay subida de fotos, las fotos las tiene que subir con ftp,
    flickr o lo que quiera, la aplicación sólo soporta que le indiques un
    número de urls que corresponden con las fotos. Las urls se insertan en
    un unico campo de texto separado por saltos de carro. La aplicación no
    hará miniaturas, sino que las mostrará al tamaño deseado mediante css,
    no se indicará explícitamente cual es la foto principal del producto
    sino que se entiende que es la primera indicada.

  • No hay pasarela de pago, el vendedor y el comprador pactan una
    transferencia o lo que sea, la aplicación no gestiona esto.

  • Todo lo que tiene que ver con un Pedido se almacena en una
    sólotabla, Las Líneas de Pedido están ‘seudo-serializadas’ en un campo de
    texto en la tabla Pedidos. Tantos saltos de carro como líneas de
    pedido. Formato: “nombre producto, modelo, precio unidad, cantidad”.
    No existe ninguna relación con la tabla Productos, la
    descripción"nombre producto+modelo" debe bastar para saber inequívocamente a qué
    producto se refiere. La no-relación, permite que el Producto pueda ser
    borrado, modificado su precio o cualquier cosa pero la Línea de Pedido
    permanece invariable.

Las Líneas de Pedido se podrían haber metido fácilmente en otra tabla
pero quería quitármela por 2 razones: quería presionarme para
conseguir un modelo cuanto más pequeño mejor, quería que el modelo
pudiera ser fácilmente administrable desde un cliente de bases de
datos como PHPMyAdmin para un usuario no técnico. Si fueran dos tablas
habría que hacer una consulta más compleja para ver las Líneas de un
Pedido concreto.

  • Todo tipo de Producto comparten la misma tabla, y esta tabla soporta
    toda la combinatoria: Modelo, Cantidad en Stock, Precio unidad. Todo
    ‘seudo-serializado’ en un sólo campo de texto. Cada combinación una
    línea. Esto permite definir productos con una divergencia de
    cualidades propias infinita.

El truco está en que en la parte Modelo se define: modelo, talla,
color, variante chico-chica.

Ejemplo Camiseta “La Gallina Dañina”:
– básica chico roja XS, 5, 30
– básica chico roja M, 2, 30
– básica chica negra M, 2, 30
– vestido largo chica roja S, 3, 28
– vestido corto chica roja S, 3, 28

Ejemplo CD “Ellos”:
– mini-cd Ellos, 50, 4

Ejemplo Chapa “La Cucaracha”:
– 12cm blanca, 2, 20
– 6cm blanca, 1.50, 23

Ejemplo Libreta “Libreta de Hola Por
Qué”-- 120páginas, 2, 20
– 150páginas, 1.50, 23

Ejemplo Coche “Volvo GTOSTIA”… por poner un ejemplo
– Tapicería cuero - Casete - Acondicionador, 200000, 3
– Tapicería lana roja - Casete - Sin Acondicionador, 10000, 3

Se consigue también así que se identifique muy fácilmente el

  • Stock para la casuística: modelo, talla, color, variante chico-chica
  • Precio para la casuística: modelo, talla, color, variante chico-chica

El usuario puede elegir su combinatoria: modelo, talla, color,
variante chico-chica porque se muestran todas las combinaciones
posibles en un mismo combo.

  • No existe tabla categorías, siguiendo la misma filosofía que con la
    tabla Pedidos: quería menos tablas y quería que de un vistazo al
    registro Producto directamente en la BD se viera todo lo referente a
    el registro.

He solucionado esto con otro campo de texto en la tabla Producto donde
se pone manualmente una categoría por línea todas las categorías a las
que pertenece el producto. Haciendo así una relación ‘many-to-many’ de
una manera ‘chapucera’ ;).

Para mostrar un listado de todas las categorías existentes cargo este
campo de todos los Productos, hago un split por saltos de linea y voy
cargando un array al que luego saco su .uniq¡.

Para cargar todos los Productos de una categoría busco por like en
este campo. Puede causar problemas lo sé… :slight_smile:

TRUCO:

Ha nivel programación si que existen las clases:

  • Modelo
  • Linea de pedido

Con todos sus atributos separados. Útil para las vistas.

Osea que existe un proceso de serialización/deserialización al
guardar/cargar los Productos y los Pedidos.

CONCLUSIÓN:

Efectivamente esta implementación sólo es válida para una tienda muy
pequeña, con pocos productos, donde el administrador conoce bien los
productos.

También hay que tener mucho cuidado a la hora de administrar los
registros pues permite muchos errores.

Tampoco es válida si se trata de un negocio delicado… :slight_smile:

Además es mi primera aproximación a Rails osea que todo se perdona :DD

Saludos Gordos.
f.

PD: Vaya rollo me ha quedado… lo voy a poner en el blog :stuck_out_tongue:

PD2: Voy a mirarme que es esto del simpleDB.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs