com guardar dades variables
Rafa Pallares
- Com a pros:
- explotacio posterior falcil (llistats, consultes masives, estadistiques...) des de ACCESS I/O ODBC (generador d'informes, bussines intelligence)
- posibilitat de crear index sobre qualsevol columna
- Contres:
- Existencia de "marcianades" en el manteniment de tipus de incidencia al tenir que posar sentencies CREATE TABLE/ALTER TABLE. Posibles problemes de bloqueig de la taula al fer ALTER TABLE, etc... (les marcianades generen marcianos)
- Al eliminar un camp desapareix tota la informacio a la BBDD. Si ha sigut per error, quina putada....
- Els models en la aplicacio Rails son dinamics i s'haura de actualitzar al moment de fer el ALTER/CREATE. No se si aixo li agradara a Rails en produccio, amb requests en marxa, etc...
- Com a pros:
- La programacio del dataentry es molt senzilla
- El model Rails es unic i es estatic.
- Al eliminar un camp NO desapareix tota la informacio a la BBDD
- El manteniment de tipus de incidencia no te 'marcianades' de CREATE/ALTER TABLE
- Contres:
- No es poden crear index sobre columnes variables
- Complica la explotacio externa de la dades
- Com a pros:
- La programacio del dataentry es molt senzilla
- El models Rails son 2 i son estatics.
- Al eliminar un camp NO desapareix tota la informacio a la BBDD
- El manteniment de tipus de incidencia no te 'marcianades' de CREATE/ALTER TABLE
- es podria crear indexs (no com a la opcio1 pero ja tindriem alguna cosa).
- Contres:
- Complica la explotacio externa de la dades (pero es podria aplicar la SELECT PIVOT per aconseguir l'aplanament en una vista per a cada tipus d'incidencia)
Emili Parreño
Enviado desde mi iPhone
--
Has recibido este mensaje porque estás suscrito al grupo "Girona on Rails" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a girona...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a gironaonrail...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/gironaonrails?hl=es.
Victor Manuel Martin-Romo
Segons el que m'ha semblat entendre s'assembla molt a una historia que
varem muntar per gestionar l'inventari de certs emplaçaments i les seves
propietats.
Tots els objectes que es podien inventariar tenien unes propietats
comunes i unes altres que variaven en funció del grup de inventari.
Es va muntar amb 4 models "Grup de Inventary", "Propietats de Grup",
"Objectes" i "Object details".
En "Propietats de grup" es defineixen les propietats per a cada grup,
les validacions, etiqueta, control per el valor, valors permesos, etc
... (això es pot complicar tant com vulguis)..
Els "Object details" relacionen "Objectes"/"Propietats de Grup" i
guarda el valor d'aquestes per a cada objecte.
Fet d'aquesta manera complica una mica les selects, però si els
informes que has de treure no son molt complexes es poden fer amb prou
dignitat. Tot i això lo dels 2 milions de registres a l'any fa una mica
de por, ja que per a cada incidència es crea un registre per propietat
en la taula de detalls i això pot créixer molt si hi ha moltes
propietats...
El formulari es munta amb fent allò dels neested_attributes ...
Salut
On Wed, 8 Feb 2012 12:33:43 +0100, Emili Parreño
<emili....@gmail.com> wrote:
> Jo crec que es un clar exemple d'us d'una bbdd nosql on guardes els
> valors com a parells key-value i t'oblides de l'estructura
>
> Enviado desde mi iPhone
>
> El 08/02/2012, a las 11:47, Rafa Pallares escribió:
>
> Hola, a tots.
>
> A veure que en penseu!!!!
>
> Tinc un punt nou en la aplicacio que s'esta dessenvolupant que es una
> entrada de registre de incidencies. Aquest registre de incidencies
> esta format per uns 30 tipus de incidencies diferents (cada tipus
> d'incidencia demana diferents camps). Totes les incidencies tenen una
> serie de caps comuns o fixes (usuari, data, observacions,
> datasystem,...) i uns altres de variables que es defineixen en el
> client (OJO client=customer (persona que paga), no el navegador). Es
> preveu 500.000 incidencies l'any amb 4 camps de mitja cada una.
>
> El que fare es montar un unic formulari que sigui capaç de muntar el
> dataentry necesari en funcio de la incidencia que volem entrar.
>
> Fins aqui, es pot liar la generacio del form o no (amb Typus o
> sense), pero esta clar el que s'ha de fer. Cap problema!!!
>
> I ara be el punt de discusio: Com guardem les dades???
>
> Opcio1. En el manteniment de les definicions de les incidencies poder
> fer el create table, o alter table necesari per que rails pugui tenir
> la informacio aplanadeta, clara i bonica. Una taula plana.:
>
> * Com a pros:
>
> * explotacio posterior falcil (llistats, consultes masives,
> estadistiques...) des de ACCESS I/O ODBC (generador d'informes,
> bussines intelligence)
> * posibilitat de crear index sobre qualsevol columna
>
> * Contres:
>
> * Existencia de "marcianades" en el manteniment de tipus de
> incidencia al tenir que posar sentencies CREATE TABLE/ALTER TABLE.
> Posibles problemes de bloqueig de la taula al fer ALTER TABLE, etc...
> (les marcianades generen marcianos)
> * Al eliminar un camp desapareix tota la informacio a la BBDD. Si ha
> sigut per error, quina putada....
> * Els models en la aplicacio Rails son dinamics i s'haura de
> actualitzar al moment de fer el ALTER/CREATE. No se si aixo li
> agradara a Rails en produccio, amb requests en marxa, etc...
>
> Opcio2. Un unic model amb camp serialize:
>
> * Com a pros:
>
> * La programacio del dataentry es molt senzilla
> * El model Rails es unic i es estatic.
> * Al eliminar un camp NO desapareix tota la informacio a la BBDD
> * El manteniment de tipus de incidencia no te 'marcianades' de
> CREATE/ALTER TABLE
>
> * Contres:
>
> * No es poden crear index sobre columnes variables
> * Complica la explotacio externa de la dades
>
> Opcio3. 2 models. Un per les dades fixes (DADESFIXES) i, en relacio
> de 1 a N (2 millons de registres al any), el model de les dades
> variables amb la seguent estructura a la BBDD
> (ID,IDDADESFIXES,CODEFIELD,VALUEFIELD):
>
> * Com a pros:
>
> * La programacio del dataentry es molt senzilla
> * El models Rails son 2 i son estatics.
> * Al eliminar un camp NO desapareix tota la informacio a la BBDD
> * El manteniment de tipus de incidencia no te 'marcianades' de
> CREATE/ALTER TABLE
> * es podria crear indexs (no com a la opcio1 pero ja tindriem alguna
> cosa).
>
> * Contres:
>
> * Complica la explotacio externa de la dades (pero es podria aplicar
> la SELECT PIVOT per aconseguir l'aplanament en una vista per a cada
> tipus d'incidencia)
>
> A mida que he anat escribint m'he decantat per la opcio3, pero
> vosaltres que en penseu?
>
> Rafa Pallares
> rpc...@gmail.com [2]
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "Girona on
> Rails" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo
> electrónico a girona...@googlegroups.com [3].
> Para anular tu suscripción a este grupo, envía un correo
> electrónico a gironaonrail...@googlegroups.com [4]
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/gironaonrails?hl=es [5].
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "Girona on
> Rails" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo
> electrónico a girona...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo
> electrónico a gironaonrail...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/gironaonrails?hl=es.
>
>
> Links:
> ------
> [1] mailto:rpc...@gmail.com
> [2] mailto:rpc...@gmail.com
> [3] mailto:girona...@googlegroups.com
> [4] mailto:gironaonrail...@googlegroups.com
> [5] http://groups.google.com/group/gironaonrails?hl=es