Per defecte i fins que no es fa una compactació de la base de dades CouchDB permet fins a 1000 revisions d’un document, cosa que sovint no acostuma a ser necessari. Així doncs, si volem canviar aquesta paràmetre finalment a la versió 0.11 ja el podem canviar.
Abans de parlar de CouchDB, si no heu sentit a parlar mai de les bases de dades NoSQL, és important que sapigueu que no són bases de dades ralacionals, ni orientades a objectes. Sinó que es basen en un paradigme diferet, són orientades a documents.
Doncs bé, CouchDB és un projecte de la fundació Apache i és OpenSource, és clar. Algunes de les seves característiques són:
RESTful API
schema-less document store (document=JSON format w/binary support like attachments)
multi-version-concurrency-control model
user-defined query structured as map/reduce (javascript, python, C, etc)
incremental index update mechanism
multi-master replication
easily distributable
update validation
programat amb erlang
web based basic admin features
binding for python, C, .NET, PHP, Ruby, etc.
pros: retrieve information, cons: insert data
Actualment estic estudiant si usar aquest producte en un dels projectes que estic treballant. De fet, encara no tinc clar si aplica al 100% a les necessitats que tinc en el projecte però a priori s’ajusta prou bé. Perquè no penseu que això és una raresa que no coneix ningú informar-vos que Ubuntu One usa couchDB com a backend, pels que no conegueu el servei jo el vaig descobrir gràcies a l’article d’Ars Technica: Code tutorial: make your application sync with Ubuntu One.
Inicialment volia fer un manual de les funcions bàsiques de CouchDB però degut al munt de documentació que he trobat he pensat que era una tonteria re-inventar la roda, així doncs a continuació faré una ressenya de les fonts d’informació que he usat per coneixer aquesta base de dades:
CouchDB Implementation: descripció molt detallada i no massa extensa de com funciona per dintre aquest sistema de BBDD especialment dedicada al Pau. Destaco aquest paràgraf:
CouchDB is a “document-oriented” database where document is a JSON string (with an optional binary attachment). The underlying structure is composed of a “storage” as well as multiple “view indexes”. The “storage” is used to store the documents and the “view indexes” is used for query processing.
Abans d’acabar comentar que personalmentel que més m’ha costat d’entendre de tot plegat és el tema map/reduce especialment la part de reduce, ja que no acabava de veure al 100% com funcionava i quina finalitat tenia. Potser l’error més gran que he comès és intentar buscar un paral·lelísme directe entre SQL i NoSQL. Sota el meu punt de vista no són tecnologies substitutories, més aviat complementaries ja que cada una s’ajusta a un tipus de solucions diferents. Per tant, abans que res recomano que confronteu la vostre problemàtica amb cada un dels paradigmes: orientat a objectes, bbdd relacionals i orientat a documents.
Gràcies a l’Aitor descubreixo el GreenSQL, una aplicació en forma de dimoni que fa funcions de reverse proxy entre les aplicacions que usen MySQL i el servidor de MySQL. Després de revisar la pàgina web, una presentació i veure una demostració del seu panell de control he de dir que l’eina té molt bona pinta. El seu mètode de funcionament ens pot portar a alguns mals de caps ja que fins que les whitelist no tenen suficient informació de com funcionen les nostres aplicacions alguns falsos positius en els seus anàlisis ens poden fer tornar una mica bojos. Malgrat això en alguns entorns crec que l’eina pot ser molt útil. El que no he sabut trobar per enlloc és un benchmark de quin és el rendiment d’aquest proxy ja que per entorns de molta càrrega crec que podria convertir-se en un coll d’ampolla. Finalment una altre informació que no he sabut trobar és on guarda la seva base de dades d’informació??? ja que el volum d’aquesta pot ser molt gran i seria curiós saber si ho fa també sobre MySQL o sobre fitxers de text, tipus sqlite o BerkeleyDB, per exemple.
La idea que es persegueix al usar múltiples esquemes en un sol projecte és la de poder usar múltiples bases de dades en un sol projecte. La idea sembla molt senzilla, però a través de la documentació oficial del projecte Symfony la veritat és que no he sabut trobar la solució. En l’explicació per portar a terme aquesta funcionalitat hem referiré tota l’estona als fitxers .yml i no als .xml equivalents, però suposo que la idea és totalment exportable.
Es tracta de deixar d’usar el fitxer schemal.yml i passar a usar diferents fitxers anomentats nomarbitrari_schema.yml, si encomptes d’un nom voleu usar un número tampoc hi ha problemes per fer-ho, per exemple, 1_schema.yml i successius.
Pel que fa al contingut d’aquests fitxers és el de sempre, tot i que jo ús recomanaria usar petites ajudes com aquesta:
Aquest nombasededades l’usarem després per especificar les dades de connexió al fitxer databases.yml, però potser el més interessant és fixar-se en el paràmetre package que ens permet que tot el model de dades quedi guardat dins de lib/model/nombasedades. O sigui, que tot queda molt més ben organitzat i fàcil d’accedir.
Cal que vigileu si dues bases de dades tenen dues taules que s’anomenen igual, ja que si això passa llavors hi haurà un conflicte en els models de dades que es generen, perquè aquestes tindran el mateix nom. Això és fàcilment solucionable simplement a l’schema heu de dir-li que el nom de la classe que representa les dades d’aquella taula de la base de dades és un nom diferent al de la taula, o sigui, el nom escollit per defecte.
Pel que fa al fitxer databases.yml el seu contingut és el de sempre, simplement cal que penseu que cal descriure la connexió de cada una de les bases de dades que heu anat declarant als diferents fitxers d’schema.yml, un exemple:
Malgrat fa molt de temps que no programo amb PHP ‘a pel’, és a dir, sense passar per Symfony ahir l’Albert em va fer saber que s’ha currat una llibreria en PHP que permet mostrar dades de forma paginada amb la usabilitat que ens dona AJAX i que és senzillíssima d’usar. Si no disposeu d’un framework que ús ofereixi una solució decent a aquest problema la solució de l’Albert és molt elegant i decent, ús la recomano.
accTable Project: lliberia PHP amb suport d’AJAX per mostrar dades paginades, feta per l’Albert Coronado.
Albert, la meva recomanació seria que li donessis la forma de plugin i l’elavoressis per diferents frameworks, per exemple, per Symfony.
IMPORTANT correcció: perdoneu l’errada però la llibreria és purament AJAX, o sigui, JavaScript obviament es pot usar igual en PHP que en qualsevol altre llenguatge. Demano disculpes per l’errada.
Propel és un framework de PHP que permet accedir a les bases de dades usant objectes, ens ofereix una API molt senzilla que és capaç de filtrar les queries contra la base de dades perquè sigui completament transparents a la nostre aplicació. Perquè ens entenguem estem parlant de coses que de ben segur coneixeu com ara el DAO o el ORM.
Per fer-nos una idea per definir l’estructura d’una base de dades només cal que escribim un fitxer XML amb els camps de les taules, tipus, relacions, etc i el Propel farà la resta. Llavors el Propel es posa a generar totes les classes automàticament, i els fitxers .sql amb els esquemes de definició de les bases de dades. Amb les classes que ens ha generat el Propel podem accedir a totes les funcions bàsiques d’accés a la base de dades és el que se’n diu CRUD (def.wikipedia).
Si voleu aprofundir en tema us recomano que seguiu els passos que vaig seguir jo i amb 30min us sentireu com de la família:
QuickStart – Com crear les BBDD, taules i altre elements al voltant de les dades per tal de poder treballar de forma trivial amb elles
CRUD explica com usar les funcions bàsiques de CRUD amb Propel.
Esquemes dels fitxers XML. Quan definim l’esquema de la BBDD ens interessa coneixer a fons la sintaxis suportada per tal d’aprofitar al màxim les funcions del propel
Relacions entre taules. Donant una mica d’emoció a les dades, usant relacions entre taules senzilles.
Captura d’errors. Si ens interessa unificar les sortides d’error de Propel és molt senzill fer-ho.
Les relacions many-to-many (molts-a-molts) no estan suportades directament pel propel i s’han de fer a través d’una taula intermitja. Malgrat ens permet sortir del pas és un dels punts a evolucionar dins de propel. Si ens interessa millorar aquesta part podem incloure les nostres classes que implementin això pel nostre codi sense problemes dins de l’estructura estàndard del propel. De moment, si ho volem fer tal i com ens proposa el manual.
