Veţi spune, cu siguranţă, că o teorie a nimicului nu prea are ce să caute într-o revistă de tehnologie. Poate că aşa este. Dar câteva note despre practica nimicului nu ar fi chiar lipsite de interes, chiar dacă a trasa o limită clară între teorie şi practică nu este o încercare chiar atât de uşoară cum ar putea să pară la prima vedere.

Povestea este simplă: clientul vrea o aplicaţie de baze de date, repede. Datele sunt în diverse locuri, trebuie asamblate, încărcate, iar primul raport trebuie să iasă peste două săptămâni. Aplicaţia ar trebui să ruleze în intranet, pe tehnologie Web, dar termenul scurt mă obligă la o variantă client/server simplă, cu un SGBD pe Unix şi aplicaţii client scrise într-un limbaj compilat pe Windows. Inevitabil (în cazul dat), interfaţa cu baza de date se face prin ODBC.

Desigur, datele sunt incomplete, aşa că unele câmpuri nu vor conţine nimic. Sau poate ar fi mai corect să spun: unele câmpuri vor conţine nimic. Oricum, din momentul în care am zis "câmpuri" am păcătuit faţă de teoria relaţională: la intersecţia liniilor cu coloanele sunt valori. Dar nimic este o valoare? Teoreticienii s-au certat mult pe tema asta şi compromisul acceptat a fost să folosească un marcaj care să specifice că acolo nu este nimic. I-au zis NULL şi s-a dezvoltat o logică trivalentă pentru această pseudo-valoare.

Dar avem oare vreme de subtilităţile acestea teoretice? Repede, aplicaţiile! Însă necazurile nu sunt doar teoretice: oare ce primeşte limbajul meu ultra-tipizat (Oberon) prin driverul ODBC când linia din baza de date conţine un NULL? Surpriză! Dacă e vorba de un atribut de tip şir de caractere, primeşte un string vid. Încerc să-mi creez variabila din program ca pointer la string şi sper să găsesc acolo un NIL. Nu. ODBC-ul aduce o valoare iar programul, civilizat, o stochează: string vid. Hmmm... Şi cum o să fac diferenţa dintre atributele NULL (lipseşte valoarea) şi cele care efectiv conţin valoarea string vid? Mă grăbesc şi nu mă interesează... Ce mi-e NULL şi ce mi-e stringul vid? În schimb atunci când am un NULL dintr-un câmp întreg şi îmi aduce valoarea zero, parcă-parcă începe să mă deranjeze...

Ok, raportul a ieşit la timp. Trec la aplicaţia Web. S-a terminat şi cu tipizarea strictă iar limbajul de scripting pe care-l folosesc (ceva asemănător cu Php) mă lasă să fac orice. De pildă, să testez o variabilă. Foarte comod: primesc fals dacă variabila nu există, dar şi dacă există şi are ca valoare un string vid, un zero, o listă vidă etc. În nimicnicia mea, abuzez de această atât de comodă facilitate, precum şi de siguranţa că din baza de date voi primi o valoare, fie ea şi stringul vid.

În fine, totul funcţionează, dar clientul vrea ca aplicaţia să se mute pe Unix. Nici o problemă, totul rămâne la fel, trebuie doar schimbată interfaţa la baza de date. Mda, numai că noua interfaţă (bazată pe Python) face singurul lucru de bun simţ care se poate imagina în materie de transportat nimic: aduce None. Care None, când este concatenat cu un string, produce o eroare. Iar magica funcţie care-mi converteşte orice în string produce, desigur, stringul "None".

Ce a urmat este uşor de ghicit: o săptămână de depanare plicticoasă, în care n-am făcut altceva decât să tratez situaţiile în care exista fie şi cea mai minusculă şansă ca din baza de date să-mi sosească un NULL.

Totul e bine când se termină cu bine, îmi veţi spune. Într-adevăr, însă povestea nu se termină aici. Un alt client se interesează de aplicaţie şi, desigur, îl interesează platforma pe care rulează. "Oricare", îi răspund cu mândrie. "Perfect, pentru că la mine totul este Windows". Cu alte cuvinte, interfaţă ODBC la baza de date, cu consecinţa imediată că nimicul redevine valoare.

Este costisitor să întreţii versiuni multiple ale aceleiaşi aplicaţii. A trebuit să găsesc o soluţie care să funcţioneze corect indiferent de platformă, mai precis indiferent de conectorul la baza de date. Iar soluţia a fost să reduc totul la cel mai mic numitor comun, adică să emulez comportamentul ODBC printr-un conector mult mai avansat.

* * *

Morala? Lanţul nu este mai puternic decât cea mai slabă verigă a sa iar lumea tehnologiilor informatice ne arată o mulţime de exemple în care cele mai avansate soluţii tehnice sunt compromise de obscure detalii de natură istorică.

E suficient să ne gândim la necazurile care se leagă de folosirea caracterelor româneşti în documente şi aplicaţii... Dar despre asta vom vorbi cu alt prilej.