du e company, era Re: [Soci SLIP] Spazio disco in esaurimento

[loredana]

On Sun, 2012-02-05 at 09:45 +0100, Lucio Crusca wrote:
> In data sabato 4 febbraio 2012 15:40:25, loredana ha scritto:
> > Mi spiace, ma non mi becchi piu', discutitela da te :)
>
> Ok, sei libera di non rispondere ovviamente, ma non è che volessi intavolare
> una discussione, ci tenevo solo a dare informazioni il più possibile corrette.

Allora bisogna che ti risponda, alcune non sono corrette. Ma niente
aggressioni e nessuna frase fuori misura, per piacere.

> Il problema però è che al 99% avremo a che fare con la larga maggioranza, che
> considera un database relazionale come qualcosa di molto più complesso e
> funzionalmente articolato di un file di testo con i comandi sort, uniq e join.
> Tutto lì. Dire che un database relazionale è solo quello va bene se ci metti
> assieme la parola "teoricamente".

Se vuoi, possiamo dire "essenzialmente". Non c'e' un solo database che
non usi sort, uniq e join (non necessariamente i comandi bash,
ovviamente, le OPERAZIONI di sort, uniq, join). Casomai mancavano grep
(selezione per righe) e cut (selezione per colonne) e gli operatori
logici (and, or, not etc). Di nuovo, non necessariamente quelli di bash,
le operazioni relative, che permettono di selezionare record e
proprieta'. Non ho messo l'intero elenco perche' era gia' fuori tema
cosi'. Il soggetto del messaggio precedente non erano i database
relazionali, mi e' solo scappato l'esempio perche' trovo quei comandi
molto utili e potenti.

> > Per tutti gli altri: Un database relazionale e' una tabella + indici.
>
> Sì, teoricamente questo sarebbe sufficiente a guadagnare il nome di database
> relazionale, anzi a tal fine gli indici sono già di troppo. Solo a livello
> accademico però, a livello di pura disquisizione fillosofica su cosa possa
> essere chiamato RDBMS e cosa no. Fuori dal mondo accademico, nel mondo di chi
> il software si trova a scriverlo e non solo a teorizzarlo, il database
> relazionale, se non ha almeno un altro centinaio di funzionalità integrate,
> sostanzialmente non serve a nulla e fa ridere, al più.

Buon divertimento. Vedi piu' giu' per una nota sul perche' non concordo
affatto su quel che dici qui. Pero' tieni a mente una cosa: io non nego
che ci siano centinaia di funzionalita' e che servano. Facciamo a
capirsi.

> Ovvero, dei database relazionali realmente utilizzati, almeno quel poco che
> basta a finire su una tabella di wikipedia, non ce n'è nemmeno uno che usi files
> di testo ed i comandi join, sort ed uniq.

Non era questo il punto, credevo fosse chiaro e, se non lo era, l'ho
spiegato per chiarezza qui sopra e qualcosa si trova anche nel resto di
questo messaggio.

Quello che intendevo dire, e' che con quei comandi ognuno di noi si puo'
gestire i suoi database relazionali o imparare a farlo. Poi li
riconoscera' ovunque e fara' meno fatica a capire le variazioni sul tema
e le funzioni aggiuntive e magari riuscira' a trovare il tasto da
cliccare ovunque glielo nascondano dietro una tendina diversa o quando
glielo spostano e sapra' cosa succede (o cosa dovrebbe succedere) quando
clicca:

> > Si fanno in casa, con pochi comandi, capendo esattamente quale sia il
> > concetto di database relazionale,

> Alla fine tutto può in teoria essere chiamato database relazionale, dal file
> /etc/hosts ai log di sistema, ma anche dal filesystem al comando ls che a quel
> punto sarebbe analogo alla "SELECT" di SQL, dalla CPU alla memoria RAM,
> all'hard disk ed alla tastiera: affinché però la definizione "database
> relazionale" abbia un'utilità pratica oltre che filosofica, bisogna decidere
> cosa far rientrare e cosa no in quella definizione, altrimenti non definisce
> proprio nulla.

Il filesystem usa una struttura diversa, utilissima anche lei, ma e' un
albero (un grafo, se si considerano i link) e non e' efficiente gestire
un albero come se fosse una tabella, anche se, in teoria (questa volta
si', che c'entra la teoria) un database relazionale (quello degli
accademici) e' in grado di rappresentare qualsiasi struttura, quindi
anche un albero (ma non e' ovviamente efficiente nel farlo e per
rendersene conto basta provarci, senza andare all'universita').

Per il resto, non capisco cosa intendi per CPU e hard disk, forse
intuisco cosa intendi per RAM, certo e' vero che la tastiera e' definita
da una tabella e quando si cambia tastiera si cambia tabella, ed e' vero
che /etc/host, i files di log, moltissime altre strutture dati che
troviamo sul nostro pc sono tabelle. Molte altre sono alberi (il gia'
citato file system, che sia GNU/Linux o che sia windows o mac, ma anche
i files xml rappresentano strutture ad albero o, almeno, dovrebbero
limitarsi a quelle, rappresentare una tabella con un file xml e'
altrettanto inefficiente del rappresentare un albero con una tabella,
solo MOLTO piu' inefficiente). Di qui l'importanza di capire queste
strutture dati e come si manipolano. Perche' sono ovunque, sono poche,
sono comprensibili da tutti, sono riconoscibili da tutti, altro che
accademia.

Senza sapere nulla di rappresentazione dei caratteri neppure si
capiscono i risultati dell'operazione di sort, per esempio, che facciamo
tutti i momenti, cliccando o da linea di comando, non importa. Per non
parlare di quel che in un database (che sarebbe poi una banca dati) non
si trova piu' perche' ce l'hanno infilato con dei caratteri strani. Io
non ci vedo nulla di accademico in quello che cerco di dire. Anzi, cerco
di dirlo perche' penso che molti problemi sparirebbero, se tutti
sapessero un po' di piu' di quel che sanno quelli che tu chiami
accademici e a cui io aggiungo i tecnici illuminati (quelli si' che
hanno tutto l'interesse a nascondere). E, al contrario di molti, non
penso affatto che cio' sia impossibile. A capire l'essenziale ci
riescono tutti, e' a star dietro a tutto il resto che si vien matti e ci
si perde (io per prima).

E' come tentare di scrivere un poema senza sapere l'abc. Non basta
sapere l'abc per scrivere un poema, e non e' necessario scrivere perche'
quello che uno dice sia poetico, ma se lo si vuol scrivere, lasciare ad
altri, allora bisogna saperlo, l'abc. O avere a fianco qualcuno che lo
sappia, che pero' e' rischioso. Chi ci dice che trascriva correttamente
se non possiamo controllare perche' non sappiamo scrivere?

Loredana