[Vari] Sottospecie di contest: implementare un DBMS.

[Vincenzo1968]

Implementiamo un DBMS. Non è un contest vero e proprio. Potremo prenderci tutto il tempo che ci serve.

Per quale motivo? Non esistono già ottimi DBMS commerciali e freeware/open source?

Risposta: per pura e semplice curiosità. Per motivi didattici. Per cercare di capire gli algoritmi che stanno sotto le implementazioni dei DBMS più diffusi. etc, etc.

Che ne dite?

----------------------------------------------------------------------------------
Documentazione utile:

http://www.csd.uoc.gr/~hy460/pdf/000.pdf
http://infolab.stanford.edu/~ullman/dbsi.html

http://pages.cs.wisc.edu/~dbbook/

http://pi3.informatik.uni-mannheim.de/~moer/querycompiler.pdf
http://pi3.informatik.uni-mannheim.de/downloads/hauptstudium/ao/ws04/folien.pdf
http://pi3.informatik.uni-mannheim.de/moerkotte.html

-----------------------------------------------------------------------------------

Questi i link ai contest precedenti:

Contest 1: Bitmap (http://www.hwupgrade.it/forum/showthread.php?t=1784948)

Contest 2: Ricerca (http://www.hwupgrade.it/forum/showthread.php?t=1785752)

Contest 3: La somma (http://www.hwupgrade.it/forum/showthread.php?t=1787500)

Contest 4: DNA (http://www.hwupgrade.it/forum/showthread.php?t=1791293)

Contest 5: Sottomatrici (http://www.hwupgrade.it/forum/showthread.php?t=1799059)

Contest 6: Parsing (http://www.hwupgrade.it/forum/showthread.php?t=1850150)

Contest 7: Il lotto (http://www.hwupgrade.it/forum/showthread.php?t=1839674)

Proposta (http://www.hwupgrade.it/forum/showthread.php?t=1872715)

Contest 8: Compattamento Barionico (http://www.hwupgrade.it/forum/showthread.php?t=1877648)

Contest 9: Divisori dei numeri triangolari (http://www.hwupgrade.it/forum/showthread.php?t=1882576)

Contest 10: Numeri palindormi (Semplice) (http://www.hwupgrade.it/forum/showthread.php?t=1883750)

Contest 11: Change. NP-Hard. (http://www.hwupgrade.it/forum/showthread.php?t=1884158)

Contest 12: Il muro (http://www.hwupgrade.it/forum/showthread.php?t=1890800)

Contest 13: Date (http://www.hwupgrade.it/forum/showthread.php?t=1981159)

Contest 14: Corsa delle macchine (http://www.hwupgrade.it/forum/showthread.php?t=1982858)

Contest 15: sudoku (http://www.hwupgrade.it/forum/showthread.php?t=1995326)

Contest 16: Intervalli (http://www.hwupgrade.it/forum/showthread.php?t=2006573)

Contest 17: Compilatori e interpreti. Parte I: interpreti. (http://www.hwupgrade.it/forum/showthread.php?t=2030843)

Contest 18: T9 lookalike (http://www.hwupgrade.it/forum/showthread.php?t=2217795)

[gugoXX]

Vado via 2 settimane senza computer...
Pensero'.

Per intanto, iscritto.

[Vincenzo1968]

Non importa. Come detto sopra non c'è nessuna fretta. Possiamo impiegarci anche un anno(due, tre, la vita intera).

;)

[Vincenzo1968]

Per la documentazione si può consultare anche "The Art of Computer Programming" Vol. III, 6.5.4 Multiway Trees:

http://www-cs-faculty.stanford.edu/~knuth/

http://www-cs-faculty.stanford.edu/~knuth/taocp.html

http://www-cs-faculty.stanford.edu/~knuth/books.html

;)

[shinya]

Non ho capito: ognuno dovrebbe farsi il suo o è un progetto comune?

[Vincenzo1968]

Non ho capito: ognuno dovrebbe farsi il suo o è un progetto comune?

Ognuno può fare come vuole. Ci si può associare con altri utenti o fare tutto da soli. La cosa importante è divertirci ed imparare.

Si può contribuire anche elencando semplicemente una serie di link utili(contenenti, per esempio, pdf o ps) sull'argomento.

;)

Edit: per documentare il proprio DBMS sarebbe meglio fornire pdf o ps invece di scrivere post chilometrici. Potete creare i documenti con TeX Live:

http://www.tug.org/texlive/

o col vostro editor WYSIWYG(l'avrò scritto nel modo giusto?) preferito.

[nico159]

Secondo me, introdurre qualcosa di nuovo (come ha fatto CouchDB http://en.wikipedia.org/wiki/CouchDB) oppure creare qualcosa di specializzato (come VoltDB http://en.wikipedia.org/wiki/VoltDB che è nato per girare interamente in ram) darebbe una spinta in più al progetto, una ragione di esistere

[Vincenzo1968]

Ciao Nico,

come detto sopra sei libero d'implementare il sistema nel modo che preferisci. Puoi farlo interamente da solo o ti puoi associare con qualcuno.

Io il mio lo faccio in C per la parte Server e in C++/QT per la parte Client.

[Vincenzo1968]

Ah! dimenticavo: è chiaro che, oltre alla documentazione e ai binari, bisogna fornire il codice sorgente.

;)

[Vincenzo1968]

scusate ma non ho capito lo scopo del contest...potreste spiegarvi meglio?


Implementiamo un DBMS. Non è un contest vero e proprio. Potremo prenderci tutto il tempo che ci serve.

Per quale motivo? Non esistono già ottimi DBMS commerciali e freeware/open source?

Risposta: per pura e semplice curiosità. Per motivi didattici. Per cercare di capire gli algoritmi che stanno sotto le implementazioni dei DBMS più diffusi. etc, etc.

...


http://www.hwupgrade.it/forum/showpost.php?p=1554131&postcount=27

Data Base Management System

SQL Server, MySQL, Oracle...

E' molto istruttivo perchè impari a lavorare con i file, con le strutture, volendo ti devi fare anche l'interprete SQL...poi andando avanti ci puoi aggiungere ciò che ti pare... Connessione tramite socket (quindi internet)... E' davvero completo come percorso di apprendimento...

Ovviamanete ci dovresti lavorare molto e dovresti studiare molto...

;)

[msangi]

Contest molto interessante

[Vincenzo1968]

Dunque, i moduli inizialiali in cui vorrei suddividere il programma sono i seguenti:

- File manager
- Buffer Manager

Il file manager tiene traccia dello spazio disponibile su disco e si occupa dell'organizzazione fisica di record e campi.
Il buffer manager si occupa di allocare e gestire le pagine di 4 KB quando il file manager deve leggere/memorizzare uno o più record.
Per gli indici utilizzerò i B+Tree.

http://en.wikipedia.org/wiki/B%2B_tree
http://www.cecs.csulb.edu/~monge/classes/share/B+TreeIndexes.html

I documenti originali:

http://www.liacs.nl/~graaf/STUDENTENSEMINARIUM/OMLO.pdf

http://people.cs.aau.dk/~simas/aalg06/UbiquitBtree.pdf

[Vincenzo1968]

In Windows posso utilizzare la funzione api GetSystemInfo per sapere la dimensione di una pagina(tramite il campo dwPageSize della struct SYSTEM_INFO):

http://msdn.microsoft.com/it-it/library/windows/desktop/ms724381%28v=vs.85%29.aspx

http://msdn.microsoft.com/it-it/library/windows/desktop/ms724958%28v=vs.85%29.aspx

http://msdn.microsoft.com/it-it/library/windows/desktop/ms724423%28v=vs.85%29.aspx

E Linux? Come faccio? E dove la trovo la documentazione della api? La trovo da qualche parte nel sistema o la devo scaricare? E da dove? Che libri devo comprare?

[The_ouroboros]

http://www.cyberciti.biz/faq/linux-check-the-size-of-pagesize/

[Vincenzo1968]

Grazie mille The_ouroboros! :D

Ho deciso di comprare questo libro:

http://my.safaribooksonline.com/static/201212-7012-my/images/9780321638014/9780321638014_s.jpg

http://my.safaribooksonline.com/book/programming/unix/9780321638014

Ho trovato anche questo corso:

http://www.cs.stevens.edu/~jschauma/631/

:yeah: :winner: :yeah:

[The_ouroboros]

Grazie mille The_ouroboros! :D

Ho deciso di comprare questo libro:

http://my.safaribooksonline.com/static/201212-7012-my/images/9780321638014/9780321638014_s.jpg

http://my.safaribooksonline.com/book/programming/unix/9780321638014

nulla, nel mio piccolo voglio aiutare :D

p.s: libricino :eek:

[Vincenzo1968]

Aspetta, aspetta...

Nel link che mi hai segnalato c'è il comando da digitare nella shell. Nel mio sistema restituisce 4096.

Io cerco una funzione api in modo da ricevere l'informazione via codice C. Mo vedo nel corso online che ho trovato.

Grazie comunque :) ;)

[The_ouroboros]

Aspetta, aspetta...

Nel link che mi hai segnalato c'è il comando da digitare nella shell. Nel mio sistema restituisce 4096.

Io cerco una funzione api in modo da ricevere l'informazione via codice C. Mo vedo nel corso online che ho trovato.

Grazie comunque :) ;)

mmm... forse con sysctl o giu per quella strada :stordita:

[Vincenzo1968]

Trovato "sysconf":

http://linux.die.net/man/3/sysconf
http://linux.die.net/man/2/getpagesize

http://www.kernel.org/doc/man-pages/online/pages/man3/sysconf.3.html

http://nadeausoftware.com/articles/2012/09/c_c_tip_how_get_physical_memory_size_system

:yeah: :winner: :yeah:

[ingframin]

Io ho iniziato a scrivere questo:

class Node:
def __init__(self):
self.content = []
self.left = None
self.middle = None
self.right = None


def insert(self,v):
if len(self.content) == 0:
self.content.append(v)
return

if len(self.content) == 1:
self.content.append(v)
self.content.sort()
return

if len(self.content) == 2:
if v>self.content[0] and v<self.content[1]:
if self.middle is None:
self.middle = Node()
self.middle.insert(v)
else:
self.middle.insert(v)

return

if v<self.content[0]:
if self.left is None:
self.left = Node()

self.left.insert(v)
return

if v>self.content[1]:
if self.right is None:
self.right = Node()
self.right.insert(v)
return

def search(self,v):
try:
if v in self.content:
return (self.content,self.content.index(v))
elif v<self.content[0]:
return self.left.search(v)
elif v>self.content[0] and v<self.content[1]:
return self.middle.search(v)
else:
return self.right.search(v)
except:
raise KeyError

Che e' l'inizio di implementazione di un B-tree in Python.
Una volta che ho capito come funziona poi posso o passare a cose piu' sofisticate tipo B+tree o B*tree et similia oppure posso implementarlo in C e fare un modulo richiamabile da Python.
Ogni commento sul mio codice e' bene accetto :)

[Vincenzo1968]

Io ho iniziato a scrivere questo:
...
Che e' l'inizio di implementazione di un B-tree in Python.
Una volta che ho capito come funziona poi posso o passare a cose piu' sofisticate tipo B+tree o B*tree et similia oppure posso implementarlo in C e fare un modulo richiamabile da Python.
Ogni commento sul mio codice e' bene accetto :)

Ottimo. Commenti particolari sul tuo codice non ne posso fare ché Python non lo conosco bene. Spiega l'algoritmo in modo da agevolare chi si avvicina per la prima volta all'argomento.

I B+Tree sono una variante, proposta da Knuth, dei B-Tree. Memorizzano i dati solo sulle foglie. I nodi interni contengono solamente le chiavi. L'albero è più efficiente visto che in questo modo si riduce la sua altezza(e, dunque, si riducono gli accessi al disco fisso.

Trovi maggiori informazioni nel pdf di Comer: http://people.cs.aau.dk/~simas/aalg06/UbiquitBtree.pdf

[The_ouroboros]

io ho approfittato di questa discussione e mi sono regalato per natale Introduction to Algorithms di Cormen (http://www.amazon.co.uk/gp/product/8120340078/ref=oh_details_o00_s00_i00) che era da un po che volevo prendermi :cool:

[ingframin]

Dunque, premetto che l'implementazione che ho postato e' una mia interpretazione di cio' che ricordo dei B-tree studiati a basi di dati 5 anni fa,
quindi... sono abbastanza arrugginito :D
Comunque ogni nodo ha 2 chiavi e 3 puntatori.
Quando si inserisce una chiave prima di tutto si controlla che il nodo base abbia slot vuoti e in quel caso ci si mette dentro la chiave.
Altrimenti se il nodo base e' pieno si fa un confronto tra la chiave da inserire e le chiavi presenti nel nodo: Se la nuova chiave e' piu' piccola della chiave piu' piccola va in un nodo a sinistra (nodo left), se e' contenuta tra le due va al centro (nodo middle) se e' piu' grande va a destra (nodo right). Ovviamente la faccenda e' ricorsiva e va avanti finche' non si trova un posto per infilare la nuova chiave.
Purtroppo non si autobilancia, mi devo essere scordato qualcosa, ho letto su wikipedia dei nodi che vanno splittati ma comunque... ci penso dopo, non mi cambia molto questa cosa.
La ricerca non fa altro che cercare il valore v tra i vari nodi seguendo il percorso stabilito. Quando la trova restituisce il contenuto del nodo e l'indice in cui trovare v (ancora sto solo giocando con le chiavi, associare poi dei valori alle chiavi e' facile). Se non trova niente emette un KeyError che vuol dire chiave non trovata (e' lo stesso che si usa se una chiave non sta in un dizionario).
Ancora mancano:
1) associazione valore - chiave
2) cancellazione di un nodo
3) bilanciamento dell'albero
4) __getitem__ e __setitem__ in modo da poter accedere agli elementi come tree[key] come se fosse un dizionario di python

Quando tutto sara' completo faccio profiling e se va piano lo riscrivo in C usando questa classe come wrapper per la dll (o .so per i linuxari) creata.
E poi si va avanti col resto...
Avevo pensato a un database NoSQL. Vorrei mettere in piedi un linguaggetto ad hoc semplice semplice e descrivere le tabelle con un metalinguaggio tipo JSON.
Vedremo vedremo... Se mi esce qualcosa di carino lo metto su github :)

[Vincenzo1968]

io ho approfittato di questa discussione e mi sono regalato per natale Introduction to Algorithms di Cormen (http://www.amazon.co.uk/gp/product/8120340078/ref=oh_details_o00_s00_i00) che era da un po che volevo prendermi :cool:

Gran bel libro. Nel capitolo 18(B-Alberi) trovi ciò che ti serve per l'implementazione dei B-Tree.

[Vincenzo1968]

Dunque, premetto che l'implementazione che ho postato e' una mia interpretazione di cio' che ricordo dei B-tree studiati a basi di dati 5 anni fa,
quindi... sono abbastanza arrugginito :D
Comunque ogni nodo ha 2 chiavi e 3 puntatori.

Devi modificare il codice in modo che ogni nodo contenga un numero non fisso di chiavi(altrimenti non puoi gestire le chiavi di lunghezza variabile come i varchar). Solitamente un B-Tree(o le varianti B+Tree, B*Tree, etc) contengono centinaia di chiavi(e, dunque, centinaia + 1 puntatori) in modo da ridurre l'altezza dell'albero.


Quando si inserisce una chiave prima di tutto si controlla che il nodo base abbia slot vuoti e in quel caso ci si mette dentro la chiave.
Altrimenti se il nodo base e' pieno si fa un confronto tra la chiave da inserire e le chiavi presenti nel nodo: Se la nuova chiave e' piu' piccola della chiave piu' piccola va in un nodo a sinistra (nodo left), se e' contenuta tra le due va al centro (nodo middle) se e' piu' grande va a destra (nodo right). Ovviamente la faccenda e' ricorsiva e va avanti finche' non si trova un posto per infilare la nuova chiave.
Purtroppo non si autobilancia, mi devo essere scordato qualcosa, ho letto su wikipedia dei nodi che vanno splittati ma comunque... ci penso dopo, non mi cambia molto questa cosa.
La ricerca non fa altro che cercare il valore v tra i vari nodi seguendo il percorso stabilito. Quando la trova restituisce il contenuto del nodo e l'indice in cui trovare v (ancora sto solo giocando con le chiavi, associare poi dei valori alle chiavi e' facile). Se non trova niente emette un KeyError che vuol dire chiave non trovata (e' lo stesso che si usa se una chiave non sta in un dizionario).
Ancora mancano:
1) associazione valore - chiave
2) cancellazione di un nodo
3) bilanciamento dell'albero
4) __getitem__ e __setitem__ in modo da poter accedere agli elementi come tree[key] come se fosse un dizionario di python

Quando tutto sara' completo faccio profiling e se va piano lo riscrivo in C usando questa classe come wrapper per la dll (o .so per i linuxari) creata.
E poi si va avanti col resto...
Avevo pensato a un database NoSQL. Vorrei mettere in piedi un linguaggetto ad hoc semplice semplice e descrivere le tabelle con un metalinguaggio tipo JSON.
Vedremo vedremo... Se mi esce qualcosa di carino lo metto su github :)

Abbiamo tutto il tempo. ;)

[The_ouroboros]

io, lavoro permettendo, mi aggiungo al progetto (che uso per recuperare un po di ATD).
Sempre se mi volete :D

P.S: in effetti, un parser JSON(o l'ambito NOSQL cmq) è una cosa che mi buzza nelle orecchie da un pò.

[ingframin]

Devi modificare il codice in modo che ogni nodo contenga un numero non fisso di chiavi(altrimenti non puoi gestire le chiavi di lunghezza variabile come i varchar).

Questa non l'ho capita... Ho messo le chiavi in una lista di due elementi ma non c'e' nessun vincolo sull'oggetto che uso come chiave. Le liste di Python non devono essere per forza omogenee. Credo che il problema si ponga in linguaggi
tipati staticamente come il C dove se una chiave non mi entra in uno slot devo spalmarla su piu' slot o sbaglio?

[Vincenzo1968]

io, lavoro permettendo, mi aggiungo al progetto (che uso per recuperare un po di ATD).
Sempre se mi volete :D

P.S: in effetti, un parser JSON(o l'ambito NOSQL cmq) è una cosa che mi buzza nelle orecchie da un pò.

Certo che ti vogliamo ma non è un progetto unico. Ognuno sviluppa il proprio DBMS. Se vuoi puoi comunque associarti al progetto di qualcun altro o chiedere a qualcuno di associarsi al tuo. ;)

[Vincenzo1968]

Io per la documentazione mi sto appoggiando a questo libro:


Autori : Ramez A. Elmastri - Shamkant B. Navathe
Titolo : Sistemi di basi di dati
Editore: Pearson - Addison Wesley
quarta edizione


Il libro è diviso in due volumi. Per l'implementazione fisica sto consultando i paragrafi seguenti:

Volume I:

13.3 Bufferizzazione di blocchi.
13.4.1 Record e tipi di record
13.4.2 File, record a lunghezza fissa e record a lunghezza variabile
13.4.3 Record con spanning e record senza spanning
Capitolo 14 - Indici per file: tutto.


Volume II:

1.1.2 Transazioni, buffer del DBMS
1.1.3 Perché è necessario il controllo di concorrenza
1.1.4 Controllo di affidabilità
1.2.1 Stati delle transazioni
1.2.2 Il log di sistema
1.2.3 Punto di commit di una transazione
1.3 Proprietà delle transazioni
1.4.1 Schedule di transazioni
2.1.1 Tipi di lock e tabelle di lock di sistema
2.1.2 Locking a 2 fasi
2.1.3 Gestione di deadlock e starvation
2.5 Granularità dei dati e locking a granularità multipla
2.6 Uso di lock per il controllo della concorrenza negli indici

[The_ouroboros]

Certo che ti vogliamo ma non è un progetto unico. Ognuno sviluppa il proprio DBMS. Se vuoi puoi comunque associarti al progetto di qualcun altro o chiedere a qualcuno di associarsi al tuo. ;)

penso che mi darò al NoSql e Json in C allora :)

[Vincenzo1968]

Questa non l'ho capita... Ho messo le chiavi in una lista di due elementi ma non c'e' nessun vincolo sull'oggetto che uso come chiave. Le liste di Python non devono essere per forza omogenee. Credo che il problema si ponga in linguaggi
tipati staticamente come il C dove se una chiave non mi entra in uno slot devo spalmarla su piu' slot o sbaglio?

Ah OK! Pensavo che ogni nodo potesse contenere soltanto due chiavi e tre puntatori. In questo modo l'albero sarebbe stato inefficiente(perché di altezza troppo elevata).
Te l'ho detto: non conosco bene Python(anzi non lo conosco quasi per niente).

Chiedo venia. :D

[Vincenzo1968]

Per l'organizzazione fisica dei file è utile anche questo libro:


Folk et al. - File Structures - An Object-Oriented Aproach with C++ (Addison-Wesley, 1998)


Non è più in produzione ma si piò trovare usato su Amazon.
I capitoli 9 e 10 spiegano, rispettivamente, i B-Tree e i B+Tree:


Cap. 9: Multilevel indexing and B-Trees
Cap. 10: Indexed sequencial file access and Prefix B+Trees


Il Prefix B+Tree è una variante dei B+Tree che consente di ottimizzare le prestazioni in caso di chiavi di tipo stringa.

Ecco il documento originale:

http://ict.pue.udlap.mx/people/carlos/is215/papers/p11-bayer.pdf

[The_ouroboros]

si potrebbe anche implementare, la butto lì, un sql più semplice con metodi REST...che ne dite? O è troppo oltre?

[Tommo]

I DBMS rappresentano tutto quello che mi annoia dell'informatica, quindi per sto giro passo :asd:

[Vincenzo1968]

si potrebbe anche implementare, la butto lì, un sql più semplice con metodi REST...che ne dite? O è troppo oltre?

Questo?

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Sembra interessante.

[Vincenzo1968]

In sostanza i windows service in Linux si chiamano "daemon"?

[Vincenzo1968]

I DBMS rappresentano tutto quello che mi annoia dell'informatica, quindi per sto giro passo :asd:

Eh ma in quanto membro anziano ti toccherà indossare il sambenito...

:D

[The_ouroboros]

Questo?

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Sembra interessante.


l'dea di base quella, si :D

[The_ouroboros]

In sostanza i windows service in Linux si chiamano "daemon"?

fondamentalmente sì.

[ingframin]

Ah OK! Pensavo che ogni nodo potesse contenere soltanto due chiavi e tre puntatori. In questo modo l'albero sarebbe stato inefficiente(perché di altezza troppo elevata).
Te l'ho detto: non conosco bene Python(anzi non lo conosco quasi per niente).

Chiedo venia. :D

Per ora l'ho fatto con 2 chiavi per nodo per capire come funziona, ma estenderlo non e' cosi complicato. Una volta che ho capito come farlo per 2 poso farlo per quante chiavi voglio.
L'importante era farlo funzionare prima per due.
Ad esempio, ancora non e' bilanciato, questa cosa va sistemata.

[Vincenzo1968]

Vediamo un esempio di B+Tree tratto dal libro:

Autori : Raghu Ramakrishnan and Johannes Gehrke
Titolo : Database Mnagement Systems


Il B+Tree è un albero bilanciato; i nodi interni contengono le chiavi e dirigono la ricerca;
i nodi foglia contengono i dati. Le foglie sono doppiamente collegate tra loro in modo da
facilitare la ricerca di intervalli di valori(es. "WHERE ID >= 5 AND ID <= 21").

Le caratteristiche di un B+Tree sono:

- Le operazioni(inserimento, modifica, cancellazione) lasciano sempre l'albero perfettamente bilanciato.

- È garantita un'occupazione minima del 50% per ogni nodo tranne che per la radice.

- La ricerca di un record richiede l'attraversamento dell'albero dalla radice alla foglia.

In un B+Tree ogni nodo contiene m elementi e d <= m <= 2d. Il valore d è detto ordine dell'albero.
Fa eccezione a questa regola il nodo radice per il quale è semplicemente richiesto che 1 <= m <= 2d.

Ogni nodo interno com m elementi contiene m+1 puntatori ai figli. Il puntatore P(i) punta al
sottoalbero in cui tutti i valori chiave K sono tali che K(i) <= K < K(i+1).
P(0) punta al sottoalbero in cui tutte le chiavi sono minori di k(1); P(m) punta al sottoalbero
in cui tutte le chiavi sono maggiori o uguali a K(m).


Un esempio di B+Tree di ordine 2(Fig. 9.10):
http://img402.imageshack.us/img402/5299/01btree.jpg

Come vedete "ordine 2" significa che ogni nodo, eccetto la radice, deve contenere un minimo di 2 e un massimo di 4 chiavi.
Per ogni nodo si hanno m+1 puntatori. Se un nodo contiene 2 chiavi, i puntatori saranno 3. Se contiene 4 chiavi, ci saranno 5 puntatori, e così via.


L'inserimento in un B+Tree avviene come segue: Si effettua una ricerca partendo dalla radice.
Se il valore viene trovato nel nodo foglia e se l'indice è univoco(non ammette duplicati), viene
restituito l'errore "valore chiave già presente").
Se, invece, l'indice non è univoco, o se il valore non viene trovato nel nodo foglia, lo si inserisce nel punto giusto,
spostando eventualmente a destra i valori maggiori.

Con riferimento al B+Tree di Fig. 9.10, se vogliamo inserire il valore 8, dobbiamo piazzarlo nella foglia più a sinistra che è già piena.
L'inserzione causa una suddivisione(splitting) della foglia. Le pagine splittate sono mostrate nella figura 9.12.
Si noti come la chiave 5, che discrimina tra le due foglie(quella più a sinistra e il nodo foglia fratello, appena creato), venga spinto su, nel nodo padre.
Ma anche il nodo padre è pieno e, dunque, dobbiamo splittarlo. l'operazione di splitting dei nodi può progagarsi fino al nodo radice e questo causa la crescita dell'altezza dell'albero.

Figg. 9.12 e 9.13:
http://img834.imageshack.us/img834/66/02btree.jpg


Ecco l'albero dopo l'inserimento della chiave 8(Fig. 9.14):
http://img834.imageshack.us/img834/2379/03btree.jpg

Una variazione dell'algoritmo di inserimento prevede la redistribuzione delle chiavi nel nodo fratello se questo ha spazio disponibile:

Fig. 9.15:
http://img17.imageshack.us/img17/4134/04btree.jpg

Come si vede la redistribuzione mantiene bassa l'altezza dell'albero e quindi la ricerca è più efficiente(si ha un minore accesso al disco).

La cancellazione di un elemento avviene come segue: si effettua una ricerca nell'albero. Se l'elemento viene trovato, lo si cancella e gli elementi alla sua destra vengono riarrangiati verso sinistra nel nodo foglia.
Se, dopo la cancellazione, il nodo non contiene il numero di elementi minimo, bisogna effetuare l'unione(merging) tra due nodi fratelli. Anche qui, come nel caso dell'inserimento, il merging può propagarsi fino al nodo radice
causando la diminuzione dell'altezza dell'albero.

Cancelliamo, ad esempio, la chiave 19. Possiamo semplicemente rimuoverla dalla foglia dove si trova. Se cancelliamo anche la chiave 20, la foglia conterrà soltanto un elemento.
Il nodo foglia fratello ha tre elementi e possiamo dunque redistribuire le chiavi tra i due nodi fratelli. Spostiamo la chiave 24 nella foglia che contiene 20 a spostiamo su, nel nodo padre, la nuova "splitting key", 27.
Il processo è illustrato nella figura 9.17:

Figg. 9.17 e 9.18:
http://img708.imageshack.us/img708/6518/05btree.jpg

Cancelliamo adesso la chiave 24. La foglia conterrà soltanto il valore 22 dopo la cancellazione e l'unico fratello contiene il numero minimo di elementi(cioè, nel nostro esempio, 2: le chiavi 27 e 29).
Dunque, in questo caso, non possiamo redistribuire le chiavi. Dobbiamo unire i due nodi fratelli. La situazione è mostrata nella figura 9.18.

La figura 9.19 mostra la situazione dopo tutti gli arrangiamenti necessari:
http://img521.imageshack.us/img521/4427/06btree.jpg

[Vincenzo1968]

Per quanto riguarda la gestione dei blocchi sto organizzando il codice come segue:

mantengo una bitmap con un bit per ogni blocco che indica se il blocco è in uso.
Il buffer manager si occupa di recuperare la pagine dal disco e, viceversa, di scrivere le modifiche intervenute nelle pagine in memoria sul disco.
Il buffer pool(la collezione di pagine in memoria) è gestito tramite due variabili: pin_count e dirty.
La prima contiene il numero di volte che una pagina è stata richiesta ma non rilasciata.
dirty è una variabile booleana che indica se la pagina è stata modificata(e quindi necessita di essere salvata su disco).

In questa prima versione non gestisco le transazioni. Assumo un sistema monoutente. Nelle versioni successive il buffer manager si dovrà occupare della gestione di due o più transazioni. Due differenti transazioni non potranno ovviamente ottenere un lock esclusivo sulla stessa pagina allo stesso tempo.

Replacement policy: uso il metodo LRU(least recently used) implementando nel buffer manager una coda di puntatori ai frame. Un frame è aggiunto alla coda quando pin_count è zero.
La pagina scelta per la sostituzione è quella che nel frame è in testa alla coda.

[khelidan1980]

io ho approfittato di questa discussione e mi sono regalato per natale Introduction to Algorithms di Cormen (http://www.amazon.co.uk/gp/product/8120340078/ref=oh_details_o00_s00_i00) che era da un po che volevo prendermi :cool:

lo usato x gli esami in università, per carità, un istituzione, ma alcune cose le da troppo per scontate, poi le soluzioni agli esercizi sono solo per i docenti, anche se online forse si trovano

[The_ouroboros]

lo usato x gli esami in università, per carità, un istituzione, ma alcune cose le da troppo per scontate, poi le soluzioni agli esercizi sono solo per i docenti, anche se online forse si trovano

a me serve come riferimento per lavoro, gli esami li ho finiti oramai (almeno quelli accademici :D )

[Vincenzo1968]

A me il Cormen è servito tantissimo. Tanti algoritmi sono spiegati in modo semplice e chiaro. Gli alberi Red-Black, per esempio, li ho facilmente implementati in C seguendo lo pseudocode del relativo capitolo.

Il capitolo 18, come dicevo prima, contiene una chiara spiegazione dei B-Tree(ma non dei B+Tree).

Il libro delle soluzioni agli esercizi me lo sono fatto dare da un mio amico professore. :cool:

[Vincenzo1968]

Record con spanning o record senza spanning? Questo è il problema. Non riesco a decidermi.

Secondo voi qual è la soluzione migliore?

[The_ouroboros]

Record con spanning o record senza spanning? Questo è il problema. Non riesco a decidermi.

Secondo voi qual è la soluzione migliore?


per una prima "stesura" meglio senza, che ne dici?

[Vincenzo1968]

per una prima "stesura" meglio senza, che ne dici?

Io direi di prendere una decisione all'inizio e adottare quella. Forse decido per i record senza spanning. Mi sembra la soluzione più efficiente dal punto di vista delle prestazioni anche se non dal punto di vista delo spazio occupato su disco.

[The_ouroboros]

Io direi di prendere una decisione all'inizio e adottare quella. Forse decido per i record senza spanning. Mi sembra la soluzione più efficiente dal punto di vista delle prestazioni anche se non dal punto di vista delo spazio occupato su disco.

se la vogliamo prendere come specifica iniziale, mi trovi concorde ;)
Oramai i GB non sono costosi come un tempo

[Vincenzo1968]

Alt! fermi tutti!

Nel caso della ricerca e dell'inserimento va bene, i record senza spanning sono più efficienti. Ma nel caso della modifica? Se l'utente modifica i dati e il record non può essere contenuto(fit) nella pagina? Bisogna cancellarlo dalla pagina corrente e piazzarlo in una nuova pagina(andando anche a modificare il puntatore nel B+Tree).

Cribbio :mad:

[The_ouroboros]

mmm.... stendi magari una lista pro/contro dei due approcci..

[Vincenzo1968]

Pensandoci bene forse conviene adottare il metodo senza spanning. In fondo le modifiche dei dati sono relativamente poco frequenti rispetto alla ricerca e all'inserimento. E non è detto che la modifica renda il record più lungo; potrebbe essere della stessa lunghezza o più corto.

Si, mi sa che scelgo questo metodo :D

[The_ouroboros]

Si, mi sa che scelgo questo metodo :D

:D

Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[ingframin]

Buon giorno ragazzi, ci sono un po' di cose che non ho capito:
1) le chiavi dell'albero che scrivo su disco, non sono le stesse chiavi che uso nelle tuple, vero? Ha piu' senso che nell'albero ci stiano delle chiavi tutte dello stesso tipo e lunghezza che siano nomi simbolici di un indirizzo di memoria da usare come base per andare a pescare il resto dell'albero... o sbaglio?
2) Ma siamo sicuri che nel corso della storia non sia stato sviluppato dell'hardware ad hoc per i database? Io credo che molte operazioni siano implementabili come un circuito e abbastanza generiche da poter essere sfruttate per un'infinita' di database diversi
3) Ma i dati da salvare non vengono compressi in nessun modo? Tipo LZMA o un altro "a caso"...

Buone feste, godetevi le ferie che a gennaio si torna a lavoro! :doh: :D

[Vincenzo1968]

Buon giorno ragazzi, ci sono un po' di cose che non ho capito:
1) le chiavi dell'albero che scrivo su disco, non sono le stesse chiavi che uso nelle tuple, vero? Ha piu' senso che nell'albero ci stiano delle chiavi tutte dello stesso tipo e lunghezza che siano nomi simbolici di un indirizzo di memoria da usare come base per andare a pescare il resto dell'albero... o sbaglio?

Dipende. Se l'indice è composto da uno o più campi tutti di lunghezza fissa, per esempio di tipo intero(4 o 8 byte) allora le chiavi in ogni nodo dell'albero sono tutte dello stesso tipo e lunghezza. E allora l'implementazione è semplice. Purtroppo bisogna gestire anche il caso di indici su campi a lunghezza variabile(come il tipo VARCHAR in SQL). E ci sono anche gli indici composti da più campi di tipo diverso(per esempio posso creare un indice su un campo intero e su un campo varchar).


2) Ma siamo sicuri che nel corso della storia non sia stato sviluppato dell'hardware ad hoc per i database? Io credo che molte operazioni siano implementabili come un circuito e abbastanza generiche da poter essere sfruttate per un'infinita' di database diversi

Nei testi che ho citato in precedenza non dice nulla in proposito.


3) Ma i dati da salvare non vengono compressi in nessun modo? Tipo LZMA o un altro "a caso"...
Buone feste, godetevi le ferie che a gennaio si torna a lavoro! :doh: :D

Si, ci sono tecniche di compressione. Il Prefix BTree comprime le chiavi nei nodi interni in modo ottimale. Dai un'occhiata al pdf che ho linkato nel primo post.
Poi ci sono tecniche per comprimere le chiavi anche nei nodi foglia. Dovrei avere qualche pdf da qualche parte. Se lo trovo lo posto. C'è anche un esempio nel sito della ibm. Devo cercare il link.

Ecco qualche link sulla cpmpressione delle chiavi:

http://ict.pue.udlap.mx/people/carlos/is215/papers/p11-bayer.pdf

http://ceur-ws.org/Vol-584/paper6.pdf

http://dev.mysql.com/doc/refman/5.5/en/innodb-compression-internals.html

http://www.vldb.org/pvldb/2/vldb09-798.pdf

http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Fc0054539.html

[Vincenzo1968]

Sto preparando un esempio di inserimento/cancellazione in un B+Tree a partire da zero. Ma devo disegnare i vari passaggi. Per il momento ecco la procedura:


Algoritmo per l'inserimento:

--------------------------------------------------------------------------------------
CASO 1: La pagina foglia non è piena; la pagina indice non è piena.

Si piazza il record in posizione ordinata, nella pagina foglia appropriata

--------------------------------------------------------------------------------------
CASO 2: La pagina foglia è piena; la pagina indice non è piena.

- 1. Bisogna dividere(split) la pagina foglia.
- 2. Si piazza la chiave mediana nella pagina indice padre, rispettando l'ordine delle chiavi.
- 3. La pagina foglia sinistra contiene le chiavi con valore minore rispetto alla chiave mediana.
- 4. La foglia destra contiene la chiavi con valore maggiore o uguale rispetto alla chiave mediana.

--------------------------------------------------------------------------------------
CASO 3: La pagina foglia è piena; la pagina indice è piena.

- 1. Bisogna dividere(split) la pagina foglia.
- 2. I record con chiavi minori rispetto alla chiave mediana vanno nella foglia sinistra.
- 3. I record con chiavi maggiori o uguali rispetto alla chiave mediana vanno nella foglia destra.
- 4. Bisogna dividere la pagina indice.
- 5. Le chiavi minori rispetto alla chiave mediana vanno nella foglia sinistra.
- 6. Le chiavi maggiori o uguali rispetto alla chiave mediana vanno nella foglia destra.
- 7. La chiave mediana va copiata(ma senza il puntatore ai dati) nella pagina indice padre(piazzandola nell'ordine giusto).

Se anche il nodo indice padre è pieno, bisogna splittarlo. Lo splitting può propagarsi fino al nodo radice causando la crescita dell'altezza dell'albero.

--------------------------------------------------------------------------------------





Algoritmo per l'eliminazione:

------------------------------------------------------------------------------------------
CASO 1: La pagina foglia non va al di sotto del fattore di riempimento; La pagina indice non va al di sotto del fattore di riempimento.

Si elimina semplicemente la chiave dalla pagina foglia. Le chiavi alla sua destra vanno spostate a sinistra di una posizione.

--------------------------------------------------------------------------------------------
CASO 2: La pagina foglia va al di sotto del fattore di riempimento; La pagina indice non va al di sotto del fattore di riempimento.

Bisogna combinare(merging) la pagina foglia con uno dei suoi fratelli. Il puntatore nella pagina indice padre va aggiustato per riflettere il cambiamento.
--------------------------------------------------------------------------------------------
CASO 3: La pagina foglia va al di sotto del fattore di riempimento; La pagina indice va al di sotto del fattore di riempimento.

- 1. Merging della foglia con uno dei suoi fratelli.
- 2. Il puntatore nel nodo indice padre va aggiustato per riflettere il cambiamento.
- 3. Merging della pagina indice padre con uno dei suoi fratelli.

Il processo continua finché non si raggiunge una pagina indice che rispetta il fattore di riempimento. Potrebbe propagarsi fino al nodo radice e questo causerebbe la decrescita dell'altezza dell'albero.

--------------------------------------------------------------------------------------------

[Vincenzo1968]

Come dicevo sopra, vediamo un esempio di inserimento/cancellazione in ub B+Tree a partire da zero. I disegni fanno un po' schifo ma non sono bravo con la grafica :fagiano:

Inizialmente il B+Tree contiene il nodo radice vuoto(che è, dunque, essendo l'unico nodo, anche un nodo foglia):

http://img109.imageshack.us/img109/8345/btreefig01.jpg

Inseriamo la prima chiave, 5:

http://img703.imageshack.us/img703/7071/btreefig02.jpg

Inseriamo la seconda chiave, 13:

http://img221.imageshack.us/img221/4282/btreefig03.jpg

Inseriamo la chiave 21:
http://img831.imageshack.us/img831/9733/btreefig04.jpg


Inseriamo la chiave 8. Si noti che le chiavi in una pagina vanno inserite nell'ordine giusto.
Quindi 8 va inserito fra la chiave 5 e la chiave 13:
http://img832.imageshack.us/img832/174/btreefig05.jpg

Inseriamo adesso la chiave 34. Notiamo che il nodo è pieno. Dobbiamo splittarlo.
La chiave mediana, 13, va copiata nel nodo padre(root). La chiave 13 nella radice contiene i
puntatori ai due nuovi figli appena creati. Il puntatore sinistro punta al nodo foglia figlio
che contiene valori < 13. Il puntatore destro punta al nodo figlio foglia che contiene valori >= 13:

http://img845.imageshack.us/img845/3763/btreefig07.jpg


L'inserimento delle chiavi 9, 10 e 55 non presenta grosse difficoltà. Vanno semplicemente inserite nelle pagine foglia nell'ordine giusto:

http://img819.imageshack.us/img819/7691/btreefig08.jpg

Per inserire le chiavi 9 e 10 effettuiamo una ricerca a partire dalla radice. Visto che la prima chiave è 13, seguiamo il puntatore di sinistra perché punta ai nodi che contengono chiavi con valore < 13. Per inserire la chiave 55 seguimo invece il puntatore destro perché punta ai nodi contenenti chiavi >= 13.

Inseriamo la chiave 1. La ricerca ci porta nella foglia più a sinistra che è piena. Bisogna dunque splittarla:

http://img707.imageshack.us/img707/2397/btreefig09.jpg

Si noti come la chiave 8 venga "copiata su" nel nodo padre.

L'inserimento della chiave 12 non comporta nessun problema. Eseguiamo la ricerca a partire dalla radice.
Seguiamo il puntatore destro della chiave 8(che è anche il puntatore sinistro della chiave 13); la ricerca termina nella foglia contenente le chiavi 8, 9 e 10.
Poiché c'è un posto libero inseriamo la chiave 12 nell'ordine giusto:

http://img16.imageshack.us/img16/4667/btreefig10.jpg


L'inserimento della chiave 35 comporta lo splitting della foglia più a destra.
La chiave mediana, 34, viene copiata su, nel nodo padre:

http://img29.imageshack.us/img29/3940/btreefig11.jpg

L'inserimento della chiave 56 è semplice:

http://img202.imageshack.us/img202/4930/btreefig13.jpg

Continua...

[Vincenzo1968]

L'inserimento della chiave 57 comporta lo splitting della foglia più a destra.
La chiave mediana, 55, viene copiata nel nodo padre:

http://img856.imageshack.us/img856/332/btreefig14.jpg


Infine, l'ultimo caso, quello più complicato. Inseriamo la chiave 11.
Dobbiamo inserirla nel nodo foglia contenente le chiavi 8, 9, 10, 12. Poiché
è pieno dobbiamo splittarlo copiando la chiave mediana, 10, nel nodo padre.
Ma anche il nodo padre è pieno. Dobbiamo splittarlo creando un nuovo nodo radice.
La chiave mediana, 13, viene "spostata su"(non "copiata su" a differenza dei nodi foglia).
L'albero cresce così di un livello:


http://img59.imageshack.us/img59/1100/btreefig15.jpg

[Vincenzo1968]

Domani vediamo i vari casi per la cancellazione di una chiave.

[Vincenzo1968]

Vediamo l'esempio per le eliminazioni di chiavi.

Riprendiamo la figura precedente:
http://img59.imageshack.us/img59/1100/btreefig15.jpg

Eliminiamo la chiave 12. Tale chiave si trova in un nodo foglia che contiene 3 chiavi(10, 11 e 12).
Dopo la sua eliminazione il fill factor è rispettato(50%, nel nostro esempio, è 2). La chiave inoltre
non compare nei nodi interni. Siamo nel caso più semplice. La cancelliamo dal nodo foglia e abbiamo finito:
http://img6.imageshack.us/img6/4773/btreefig16.jpg

Eliminiamo la chiave 9. se ci limitassimo a cancellarla, il nodo conterrebbe soltanto un elemento e non
sarebbe rispettato il fill factor(2, nel nostro esempio). Dobbiamo dunque combinare(merging) i due nodi fratelli
(il nodo che contiene le chiavi 1 e 5 e il nodo che contiene la chiave 8). Dobbiamo aggiustare anche il nodo interno
padre(il nodo che contiene le chiavi 8 e 10) altrimenti il nodo sinistro della chiave 8 punterebbe a un nodo foglia
contenente la chiave 8 e noi invece abbiamo stabilito che i puntatori sinistri puntano a nodi che contengono valori
minori rispetto alla chiave:
http://img217.imageshack.us/img217/6868/btreefig17.jpg

Il nodo interno, però, contiene soltanto una chiave(il che non rispetta il fill factor, 50%, cioè minimo due elementi per nodo, eccetto la radice).
Dobbiamo combinarlo col nodo fratello. Dobbiamo aggiustare anche il nodo radice altrimenti il puntatore sinistro della
chiave 13 non soddisferebbe le condizioni imposte:
http://img42.imageshack.us/img42/6183/btreefig18.jpg

Si noti come, dopo gli aggiustamenti necessari, l'altezza dell'albero sia diminuita di un livello.

Ok, possiamo fermarci qui con l'esempio per l'eliminazione delle chiavi. Come s'è visto l'eliminazione risulta molto più complicata
rispetto all'addizione.
È per questo motivo che in molte implementazioni di DBMS(compresi quelli commerciali, quelli famosi, Oracle, IBM, SQL Server) si
preferisce non rispettare la regola del fill factor. Un nodo viene eliminato soltanto quando si svuota completamente. Quindi, nel mondo reale, si possono avere nodi contenenti anche un solo elemento.
La pratica, anche se diffusa, è, per certi versi, discutibile. Abbiamo visto che rispettando il fill factor si riduce l'altezza dell'albero e questo consente un minore accesso al disco e, dunque, una maggiore efficienza. D'altro canto, sempre parlando d'efficienza, si pensi a un database multiutente e alla gestione della concorrenza. Ogni volta che si cancella una chiave bisogna effettuare un lock su tutte le pagine del B+Tree... non è cosa.

Personalmente, nella mia implementazione, seguirò la pratica disdicevole(ma diffusa, diffusissima) di non rispettare la regola del fill factor per le cancellazioni.

[cdimauro]

Io ho iniziato a scrivere questo:
[...]
Che e' l'inizio di implementazione di un B-tree in Python.
Una volta che ho capito come funziona poi posso o passare a cose piu' sofisticate tipo B+tree o B*tree et similia oppure posso implementarlo in C e fare un modulo richiamabile da Python.
Ogni commento sul mio codice e' bene accetto :)
L'importante è che funzioni.

Poi c'è qualcosa che si potrebbe sistemare meglio per renderlo più "pythonico", ma è roba per fissati con l'eleganza del linguaggio. :p

[Vincenzo1968]

Come esempio d'implementazione in C dei B+Tree si possono studiare i sorgenti di Tokyo Cabinet:

http://fallabs.com/tokyocabinet/

Per Windows/Visual Studio:
http://spench.net/drupal/software/tokyocabinet

È possibile studiare i sorgenti di qualche DBMS open source(PostgreSQL, MySQL, etc) ma si tratta di implementazioni con migliaia di linee di codice.
Tokyo Cabinet è più semplice ;)

[Vincenzo1968]

Vado via 2 settimane senza computer...
Pensero'.

Per intanto, iscritto.

Hai pensato?

:idea:

:cincin:

[Fixen]

Perchè limitarsi a DBMS? magari un po più di creatività sul tipo di gestione dati può far diventare più interessante il constest XD (object oriented, entity system)

[Vincenzo1968]

Perchè limitarsi a DBMS? magari un po più di creatività sul tipo di gestione dati può far diventare più interessante il constest XD (object oriented, entity system)

Ottima idea. Ognuno può regolarsi come vuole e presentare la soluzione che gli è più congeniale.

Non è neanche necessario scrivere un DBMS. Si può, per esempio, scrivere un driver ODBC per un DBMS esistente e presentare qui la propria soluzione.

Tutto ciò che concerne i database insomma. Non è un contest vero e proprio: è una sottospecie di contest. :D
Possiamo prenderci tutto il tempo che ci serve.

;)

[The_ouroboros]

Io ci sono. Con i miei tempi ma voglio realizzare un piccolo interprete x db con CRUD in base a protocollo REST.
Magari basato su un formato Json..
Così mi riprendo x bene gli adt.

I'll keep you posted =)

Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[Vincenzo1968]

Ottimo. Abbiamo tutto il tempo. Chissà quando lo finirò il mio... Tra impegni di lavoro e cavoli vari.

Anche se questo thread dovesse andare oltre la prima pagina, il primo che finisce lo riuppa e posta i sorgenti(e la documentazione).

;)

[The_ouroboros]

Ottimo. Abbiamo tutto il tempo. Chissà quando lo finirò il mio... Tra impegni di lavoro e cavoli vari.

;)

come non darti ragione.

P.S: io ho anche il mio serverino freebsd come macchina da test per chi volesse :D

[Vincenzo1968]

Una volta finita la prima release ne approfitterò sicuramente.

Thanks ;)

[vendettaaaaa]

Vincenzo, 2 domande:
1) Lavori? E dove trovi il tempo per farlo??! :D
2) Come fai ad avere solo 1250 messaggi?????

Scherzo eh! Ammiro la passione che metti in ogni messaggio!

[Vincenzo1968]

E infatti prima dicevo questo: chissà quando lo finirò.
Mi ci dedico nel tempo libero, nei fine settimana(ma non interamente).

Ma anche se dovessi finirlo fra sei mesi o un anno, non m'importa. L'argomento m'appassiona assai e, in generale, m'appassiona la programmazione di "sistema": compilatori, interpreti, sistemi operativi anche se di questi ultimi non sarei in grado di scrivere nemmeno una riga di codice :D

Per i pochi messaggi: ultimamente non ho frequentato molto il forum. Ho ripreso a frequentarlo da qualche settimana a questa parte.

[Vincenzo1968]

Comunque m'è tornata la voglia di riprendere 'sto progettino in mano. Dopo il contest 19 mi ci dedico un po'.

:D

[Vincenzo1968]

Ouro, il server pronto è? È bello caldo? Tira fuori le unghie? Ruggisce?

[The_ouroboros]

Pronto in tavola :D

Inviato dal mio LT22i con Tapatalk 2

[Vincenzo1968]

Pronto in tavola :D

Inviato dal mio LT22i con Tapatalk 2

:asd:

No, a parte gli scherzi, poi mi servirà il tuo serverino freebsd per i test.

[The_ouroboros]

:asd:

No, a parte gli scherzi, poi mi servirà il tuo serverino freebsd per i test.

come dissi a suo tempo: con piacere :D

[Mason]

Mi sembra siate orientati verso un archiviazione a record per oltp. Provate a vedere anche la memorizzazione a colonna per olap. Sicuramente molto interessante i paperi che trovate su monetdb/x100 poi sfociato in un prodotto commerciale (vectorwise o qualcosa di simile)

[Vincenzo1968]

Questo?

http://www.monetdb.org/Home

Interessante. Grazie per la segnalazione. ;)

[einstein1969]

Ci sono...

Sto implementando un piccolo programma di contabilità in partita doppia sfruttando l'excel base (dal 2002) e vba. Essendo un ex DBA Oracle qualcosina di ORDBMS ci andrà... Ma mi limito alla monoutenza per non dover pensare troppo ai deadlock e spinning vari, altrimenti una vita non basterebbe...

[Vincenzo1968]

Bene bene :D