Gracias Francesc y Raul por dejar claro que no os parecí un chapuzas 
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 
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é… 
TRUCO:
Ha nivel programación si que existen las clases:
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…
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
PD2: Voy a mirarme que es esto del simpleDB.
Gracias