Full de càlcul com a base de dades

Escrit per Aaloy a 14 de April , 2006 a les 8:36 p.m.

Llegint l'anunci al meneame i l'entrada de kexi 1 dins la distribució d'aquest paquet ofimàtic vaig enrecordar-me d'un tema que sovint em preocupa: la utilització de les fulles de càlcul com a bases de dades. És a dir, per mi per pròpia definició, una fulla de càlcul té sentit quan s'espera fer algún tipus d'operació amb les dades que conté, però quan sols serveix per que s'utilitzi l'estructura de files i columnes per fer de repositori ràpid de dades sovint em dona que pensar. Kexi és un projecte per a callar la boca a aquells que ens diuen que en aquests moments no hi ha res semblant a Access per Linux, sols per això potser s'ho val, i segur que amb el temps superarà llargament tot el que poguem trobar a l'Access. Personalment sols la idea de tenir un Python com a llenguatge d'script ja em dóna més garanties que no el que té la competència. El problema fonamental, però és que tot aquest esforç rarament es veurà recompensat en una utilització d'aquest producte per part de l'usuari mig. L'usuari mig ja se les arregla amb les fulles de càlcul. No ha de pensar en cap model relacional. Pot obrir una fulla, omplir-la de dades i anar fent. Fins i tot conec gent que es dedica professionalment a la informàtica i la seva idea màxima de magatzem de dades és un full de càlcul, perquè ja va prou bé. Això, però a la llarga suposa un problema tant per l'usuari com per l'empresa per la que fa feina. M'explicaré: El model relacional i la normalització de les bases de dades té com a objectiu que no es perdi informació a l'hora de modelar les dades i que aquesta informació no estigui duplicada. Aconseguir això amb una fulla de càlcul és complexe, ja que no estan pensades precisament per això. Està clar que cada vegada les fulles de càlcul incorporen capacitats de filtratge i cerca, més pròpies de les BD i segurament perquè algú se n'adonà que una de les màximes utilitzacions que ens feien els usuaris era aquesta. El problema, com dic, és que la gent té tendència a pensar en els fulls de càlcul com a parimera opció, sense plantejar-se si és una bona solució a mig o llarg plaç. I si ja no es plantegen això, ja no podem ni arribar a somiar que es plantegin si un motor de base de dades seria millor que les bases de dades planes. I clar, llavors venen els problemes.

• Informació duplicada, no mantinguda i repartida per infinitats de fulls de càlculs, repartis a la seva vegada per tots els ordinadors de la companyia.
• Dificulta pel saber qui té dades personal amagatzemades dins un full de càlcul. Això a la llarga pot comportar un problema importat davant l'agència de protecció de dades, ja que són fitxer de dades i com a tal s'haurien de tenir controlats. Imaginem per exemple que algú d'un gabinet mèdic duu la llista de les seves visites dins el full de càlcul. Com podrem garantir que tengui les "mesures de seguretat suficients"?. Si als cinc minuts de cercar per internet podem trobar com botar-nos l'encriptació d'un Excel. I no parlem ja de les còpies de seguretat ni registre dels acessos al sistema. Les fulles de càlcul no són per això!
• Dificultat per compartir i mantenir les dades. Les fulles de càlcul no són multiusuari, compartir les dades implica sols deixar-les en un directori comparti i sovint vol dir que s'envia per correu tota la fulla de càlcul. Què passa quan tenim les oficines connectades per una WAN? Doncs que hi ha tendència a compartir directoris sols per poder accedir a dades amagatzemades dins fulles de càlcul.
• Incapacitat de créixer. La quantitat de files que pot manejar un full de càlcul és molt limitat si ho comparam amb el que pot manegar un gestor de BD mitjà.
• Rendiment. He vist gent amb fulls de càlcul de fins a 30 MB de dades queixant-se perquè del lent que carregava l'aplicatiu. :(
• Seguretat. L'accés a la informació no està restringit de la manera com ho està una base de dades. És molt més bo de fer perdre informació, o que s'enviïn per correu electrònic les dades de l'empresa.

Tècnicament existeixen bones solucions per evitar aquests problemes. Sols fa falta dedicar un petit servidor amb espai suficient, posar en marxa un motor de base de dades (MySQL, Postgres, Firebird, ...) i donar-hi accés als usuaris. Els ISP ja tenen el tema del MySQL i el Postgres molt automatitzats, així que hi ha eines que ens permetran donar comptes d'alta molt fàcilment. Amb això tenim resolt el problema de la còpia de seguretat, de saber que tot està centralitzat i que de ser necessari es pot fer una auditoria del que hi ha per poder complir amb la llei. A més serà molt més bo de fer compartir informació entre usuaris, ja que sols es necessitarà podar-los accés al la BD de l'altra i en les condicions que nosaltres volguem. L'accés a les dades es pot fer a partir d'aplicacions web, o gestors més sofisticats si us agraden més les aplicacions de consola ( l'Squirell sql client a mi m'agrada especialment), gestors més orientats cap a l'usuari final com el mateix kexi o el gestor de l'OpenOffice, i si m'apurau qualsevol gestor que us agradi o agradi als vostres usuaris i que pugui connectar-se mitjançant ODBC o JDBC. Sigui com sigui és important fer pedagogia del que és una base de dades, de quan s'han de fer servir i del perquè les fulles de càlcul no haurien de fer-se servir com a magatzem de dades. Al mateix temps cal estar preparats per oferir una alternativa a l'usuari que li permeti seguir arreglant-se-les com sempre, però a més sabent que les seves dades estaran més protegides. Els nostres usuaris han de ser conscients de que les dades que manegen són part vital de l'empresa i que per tant no s'han de tractar amb frivolitat. Com a informàtics som responsables de donar-los l'ajuda i les eines que calguin per a que els nostres usuaris puguin fer la feina de la millor manera possible, però en aquests joc tots hi estam aficats, i per tant des de l'empresa s'ha de potenciar la utilització responsable en el maneig de les dades. Des de fa molt de temps, poder controlar les dades no és un problema de costs, gràcies als motors de codi obert tenim la possibilitat de gestionar millor les dades de la nostra empresa a un preu molt més baix que el que comporta fer servir fulls de càlcul o bases de dades planes [1]; és un problema de concienciació, de pedagogia, de voler fer les coses bé! -- [1] No ja pel cost en llicències, sinó pel cost que implica tenir que mantenir distints arxius amb les mateixes dades, pel cos d'integració de les mateixes, pels errors associats a tenir informació duplicada, etc.

Enllaços citats

• Python
• kexi
• l'anunci
• Squirell sql client
• meneame

1 comentari, 0 trackbacks (URL) , Tags: Informàtica

Bon apunt, gràcies! :)

Sovint dic que els fulls de càlcul són la resposta per a moltes necessitats d'usuaris no informàtics que volen guardar certa quantitat de dades: el paradigma de col·lumnes per camps i retxes per registres és força bo d'entendre.

Tot seguit intento explicar, perquè prenguin una bona decisió, quins són els inconvenients del full de càlcul.

Fins ara parlava del:

- Tractament per arxiu dels fulls de càlcul vs. el tractament per registres que tenen les bases de dades Com Toca (TM).

- Les dificultats per a fer connexions relacionals cap a més d'un full de càlcul.

Amb aquest apunt hi afegeixes més consideracions que tenen molt valor.