Newsgroup: it.comp.software.database
Titolo: Su MySQL e Oracle

In azienda abbiamo la versione 5.1.x di MySQL Enterprise Basic, 
comperata nel 2008, e rinnovata l'anno scorso.
Quest'anno, visto che il commerciale MySQL non ci ha cercato (forse 
perché l'amministrazione ha dimenticato di pagargli la fattura dell'anno 
scorso?), mi sono mosso io per rinnovare il contratto, e non ci sono 
riuscito.
Il link per il 'renew' dà un 404. Navigando sul sito si arriva alla 
pagina 'Buy' di MySQL, dove la stessa licenza (Standard Edition dovrebbe 
essere equivalente a Enterprise Basic) viene venduta a 1584€ contro i 
480€ (o quant'era) di un anno fa...
A sorpresa, Oracle 11 viene venduto a partire da 750€ (licenza 'named'), 
cioè Oracle ha cambiato la sua politica commerciale, da prodotto 
Enterprise costoso, a prodotto 'per tutti' (in ogni caso, se si vuole 
Oracle 11 con licenza meno 'vincolata' bisogna scucire una cifra non da 
tutti).
Penso che MySQL abbia le ore contate... Che dite, dico al capo di 
passare a  Oracle o a PostGreSQL?

Tutto abbastanza previsto nei modi... per i tempi noto una certa
fretta di monetizzare... 

 passare a  Oracle o a PostGreSQL?
Anche se avro` una vera risposta a tale quesito la settimana prossima, digli 
di passare a PostgreSQL
Enrico


Se avessi avuto 'peso' durante lo startup del progetto saremmo partiti 
direttamente con PostgreSQL. Ma la mancanza di tool gui e gli OID al 
posto dei BLOB e (a quel tempo) la mancanza di un campo auto 
incrementante hanno fatto virare la decisione verso un MySQL più 
'popolare'...
Purtroppo in azienda sono considerato come il classico 2 di picche...

 'popolare'...
Di che versione stiamo parlando? :)
Da che mi ricordo io, almeno dalla 7, e forse anche dalla 6, PotgreSQL ha 
sempre avuto sia i blob che un campo auto-incrementale (anche se 
bisognava creare una sequenza a mano, ma era un singolo comando sql). Gli 
OID non sostituiscono i BLOB, sono semplicemente campi univoci 
all'interno del DB (quindi puoi usarli come chiave primaria).
Questo almeno 8 anni fa, quando l'ho usato per la prima volta in un sito. 
Prima non so.
Bye.



Semplifico il discorso, che se racconto la storia intera facciamo una 
nuova "storia della sala macchine in 30 tomi".
Al momento di scegliere il db del progetto, facemmo delle valutazioni di 
carattere tecnico/economico. Per un altro progetto (piccolo) avevo usato 
PG 7.2 su Windows 2000, e non mi ero trovato male, per cui proposi di 
usare la versione 8.0 su Linux.
Quindi feci una piccola demo usando quello che ho sempre usato dal 1999 ad 
oggi: xterm. Non considerai che mi trovavo di fronte due dei peggiori 
doppiocliccatori del pianeta: il Technical Leader detto "Grande Pulsante 
Rosso", perché secondo lui i programmi devono lavorare tutti in batch 
mode, ed un neolaureato che non aveva mai visto una shell in vita sua.
Quando hanno scoperto che MySQL aveva un tool grafico dove potevano 
doppiocliccare a piacere, si sono calmati, ed hanno entusiasticamente 
abbracciato MySQL come salvatore della patria.
Si, lo so che c'è PGAdminIII, KPoGre ed altri, ma non reggono il confronto 
con MysqlQueryBrowser e MysqlWorkbench.
Per quanto riguarda i tipi di dato: PG usa (nella 8.x) il serial al posto 
del flag di autoincrement: di fatto è una funzione legata ad un trigger 
sull'insert. Nella 7.2 forse c'erano già, ma non li ho mai usati.
Sui blob, quelli di MySQL sono più 'semplici' da usare.
Comunque sto per iniziare un mio progetto (informatizzazione della mia 
collezione di francobolli) dove dovrò usare sia i serial che i blob, poi 
ti saprò dire.

 [...]
Ciao   Manlio

 Ciao   Manlio

 incrementante
doppio "Huh?"... il tipo campo "serial" (autoincrementante) c'e' da
almeno dieci anni (sono andato a vedere per curiosità, c'e' dalla 6.4
del '98...)
ma chi l'ha fatta la valutazione di postgreSQL, "a quel tempo"?
:^)
bye!

 lobj = connection.obj(oid=oid, mode='r')
ed usare l'API per i large object per accedere ai dati, come se fosse un 
file.
Ciao   Manlio

 bye!

 [...]
Ciao  Manlio

 sono vecchi o sono monopiattaforma
Tralasciando quelli Java, TOra e` multipiattaforma da eoni
Enrico

 digli di passare a PostgreSQL
Ok, ho una risposta: MySQL non e` fatto per determinati lavori e noi non 
siamo abituati a sviluppare (fortunatamente, direi) su MySQL. La 
considerazione proviene dall'esecuzione di una query che, su MySQL ci mette 
circa 20 minuti mentre su PostgreSQL ci mette 12 secondi e su Oracle 1 
secondo (c'e` da dire che i db si trovano su tre macchine differenti e con 
carichi differenti, ma quella carrozzata meglio e` quella con MySQL)
Enrico

 secondo
Non lasciarci sulle spine...
Come può accadere tutto ciò?
Era una query o un domandone esistenziale?
:-)
-- 
Michele

 Era una query o un domandone esistenziale?
La query in se non era complessa (si trattava di un JOIN a con b e b con c, 
a cui seguiva un GROUP BY delle colonne estratte) e nemmeno i dati 
trattati/estratti erano immensi (la tabella piu` corposa contava ~180.000 
record), ma questo non ha impedito a MySQL di generare un tempfile di 30Gb e 
di metterci 20 minuti circa per estrarre i dati (86 record in totale)
Enrico

 di metterci 20 minuti circa per estrarre i dati (86 record in totale)
Conta molto la distribuzione del carico fra le tabelle?
Esempio:
a: 1000 record;
b: 1000 record;
c: 1000 record;
è molto più difficile da gestire di:
a: 10 record;
b: 10 record;
c: 2980 record;
La massa di dati è la stessa (a parità di campi).
-- 
Michele

 Conta molto la distribuzione del carico fra le tabelle?
Direi di no, in quanto le tabelle sono disomogenee (e.g. una e` di ~180.000 
record mentre un'altra e` di 72 record)
Enrico

 Michele wrote:

Allora sono molto sorpreso perché per eseguire una query come quella di  
cui parli:
SELECT
Tabella 1: 78 record
Tabella 2: 360 record
Tabella 3: 18 934 120 record (hai capito bene) COUNT su un campo
FROM
Tabella 1  INNER JOIN Tabella 2 INNER JOIN Tabella 3
WHERE
campo = 'stringa'
GROUP BY
...
ORDER BY
...
Firebird impiega circa 10 secondi su un portatile antidiluviano con mezzo  
giga, e ricava 160 righe.
(Meno di un secondo su un SSD).
Firebird come Oracle?
Dov'è l'inghippo?
Ciao.
Michele

 Firebird come Oracle? Dov'è l'inghippo?
Sto seguendo con interesse la discussione dato che l'ottimizzazione
fisica e` un argomento per me interessante...
Per query che risultano in query plan simili, tutti i dbms
andranno uguale, nel senso che dopo aver generato un query
plan almeno decente, i dischi andranno sempre alla stessa
velocita` per qualunque dbms.
Bisogna sempre guardare come sono i piani di esecuzione, la
differenza tra i vari motori dei dbms sta soprattutto qua.
Comunque fare comparazioni e` complicato... 

 velocita` per qualunque dbms.
Non ne sono convinto, ma non saprei dire perché (sono troppo ignorante).
Però mi domando - per esempio - perché PostgreSQL, appena installato, ha  
quasi un migliaio di file di dati mentre Firebird ne ha uno solo. Una  
ragione ci sarà, e non è certo la comodità. Non è vero, poi, che alcuni  
dbms usano il filesystem e altri no, accedendo ai dati direttamente? Come?
-- 
Michele

 Dov'è l'inghippo?
L'inghippo e` che io sto parlando di MySQL :D
Enrico

 L'inghippo e` che io sto parlando di MySQL :D
Questo l'ho capito.
Ma mi sembrava meglio continuare sul solco, pur volendo spostare un po' il  
discorso, piuttosto che aprire un nuovo thread.
-- 
Michele

 altri no, accedendo ai dati direttamente? Come?
Si, alcuni hanno la possibilita' di scrivere direttamente sulle
partizioni, ma la tendenza negli ultimi anni e` di appoggiarsi
al filesystem, onde sfruttare vari benefit, tra cui il
rimappaggio automatico dei blocchi corrotti, il raid software,
l'eventuale mappaggio su unita' di rete e la possibilita' di
intervento diretto.
Il prezzo di questo e` una piccola e (nella maggior parte dei
casi) trascurabile perdita prestazionale.

 casi) trascurabile perdita prestazionale.
Grazie davvero per questa notizia.
-- 
Michele

 [...]
Ciao

 In PostgreSQL "tutto è una tabella".
Questa affermazione appare talmente ovvia da risultarmi oscura.  :o
Grazie.
-- 
Michele

 [...]
Ciao  Manlio

 indici) su file separati.
Prendo buona nota.
Grazie. Ciao.
-- 
Michele

 probabilmente lo stesso anche per MSSQL.
In Oracle, il DB, cioe' l' insieme dei dati (e degli indici, trascurando 
gli altri oggetti, per semplicita') insiste in uno o piu' Tablespace 
(uno o piu' a scelta, con caratteristiche differenti di crescita e 
frammentazione, e altri parametri che stanno oramai perdendo di 
significato), i quali si appoggiano a uno o piu' data file, tipicamente 
su "spindle" (
http://en.wikipedia.org/wiki/Spindle_%28computer%29
) 
differenti (file di file-system o dischi fisici o logici) aventi 
differenti politiche di velocita'/sicurezza/recovery.
In parole povere ci sono almeno due livelli gerarchici di scelta su come 
organizzare le cose (rispondendo anche indirettamente a "The men with 
two watches") che non appaiono nel plan di esecuzione (assieme, per 
esempio alla cardinalita' logica delle singole letture (che *potrebbe* 
non apparire/non essere calcolata) e all' impatto fisico (almeno al 
livello conosciuto dal DB).
Orizzontalmente i limiti sono molto ampi: normalmente puoi avere "tutti 
i tablespace che vuoi" e "tutti i datafile che vuoi", fino all' 
esaurimento dell' eventuale senso logico della cosa.

 [...]
Per concludere, è quindi possibile con Oracle avere una configurazione in 
cui un intero database è memorizzato all'interno di un unico file?
Ciao  Manlio

 discorso, piuttosto che aprire un nuovo thread.
Ah, ok, non mi era chiaro il tuo scopo. Come ti e` stato risposto, molto 
lavoro dipende dal query plan e dal disco, se uno dei due fallisce per 
qualche motivo (e.g. non riesce ad interpretare correttamente determinate 
query), il risultato risulta devastante per le performance di risposta delle 
query effettuate
Enrico

 dati su filesystem?
Oracle usa un modello tablespace in n datafile (dove n e` >= 1), a cui si 
aggiungono i control files e i redo log. Un database Oracle e` composto da 
almeno quattro tablespace, tre control files e un gruppo di redo log (uno o 
piu` file, se non ricordo male).
SQL Server usa un modello a due gruppi di file, uno per i dati ed uno per i 
transaction log (ogni gruppo puo` essere formato da uno o piu` file)
Enrico

 cui un intero database è memorizzato all'interno di un unico file?
No, in quanto per funzionare correttamente Oracle ha bisogno di almeno 
quattro tablespace (e quindi, quattro datafile)
Enrico

 della base dati su filesystem?
MSSQL di default 1 file per dati ed indici + 1 log.
Firebird uno solo (incluso il log)
Jet 1 per dati ed indici + 1 per il locking.
Il vecchio dbms di Borland per ciascuna tabella un file .db
(i dati) un .px (le chiavi?) un .val (sconosciuto) e credo 2
per ogni indice...
Il Foxpro, Paradox e il DBase (mi sembra) usino file separati tra
dati ed indici.
Ora e PG gia' risposto in altro mex.
MSSQL e ORA opzionale su partizioni RAW.
Si facciano avanti i supporter di DB2 e SQLite...

 Grazie davvero per questa notizia.
Aggiungo che alcuni FS avanzati che stanno maturando in questi
anni hanno caratteristiche da paura...

 marca?)
Io ho preso un Kingston 64Gb (che ha il kit per il case desktop) e mi  
trovo bene.
Gli OCZ sembrano più raffinati e più differenziati e più costosi...
-- 
Michele

 Si facciano avanti i supporter di DB2 e SQLite...
Per SQLite un file per database (ed è possibile "attaccare" diversi 
database in una sessione).
Ci sono poi altri files temporanei:
http://sqlite.org/tempfiles.html
Ciao  Manlio