Newsgroup: it.comp.programmare
Titolo: MySQL e MS SQL

Ciao a tutti
dovrei implementare un meccanismo di replica tra i 2 database in 
oggetto. Per semplicità pensavo di usare PHP ma temo per le prestazioni 
che posso avere...
Che linguaggio di programmazione mi consigliate che sia rapido sicuro e 
funzionale ? Mi spiego, vorrei generare un eseguibile per renderlo più 
performante...ho lasciato perdere .NET + SharpDevelop perchè troppo 
lenti, come piattaforma ho a disposizione sia Linux che Windows.
Grazie
ps. scusate se sono stato contorto !
Leo

 lenti, come piattaforma ho a disposizione sia Linux che Windows.
Secondo me con Python + psyco, sia su Windows sia su Linux (purche`
con CPU "tipo Intel 32bit" perche` per ora psyco supporta solo quelle),
le prestazioni dovrebbero essere buone.  Non so perche` pensi che
"generare un eseguibile" dovrebbe essere "piu` performante": psyco
e` uno "specializing compiler" -- puo` usare informazioni ottenute
a runtime per generare codice macchina piu` specializzato, e quindi
piu` performante, se identifica casi particolari che si presentano
spesso.  Questa e` la teoria, ma usandolo parecchio mi pare che esso
funzioni piuttosto bene anche in pratica (requisito principale, avere
memoria libera per tenere le diverse versioni specializzate del
codice-macchina; su di una macchina molto scarsa di memoria puo`
essere meglio fare senza psyco o usarlo in modo molto mirato solo
su eventuali specifici "colli di bottiglia").
Alex Martelli

 "generare un eseguibile" dovrebbe essere "piu` performante": 
Intanto grazie per la risposta !
Non sono un programmatore per professione, ho sempre scritto qualche 
piccolo programma in VB, C con le API e PHP.
I programmi eseguiti con programmi interprete sono più lenti (di solito) 
rispetto ai loro colleghi compilati, tutto qua... probabilmente i miei 
timori di avere database non sincronizzati non sono fondati perchè ho 
pochi dati da replicare... però volevo fare una cosa fatta bene...
Leo

 pochi dati da replicare... però volevo fare una cosa fatta bene...
Hmmm, basarsi sulla velocita` per evitare non-sincronizzazioni e`
comunque una scelta rischiosa.  Puo` andarti bene 99 volte e la
centesima no, e quando ti va male, senza sapere nulla, hai corrotto
il database di arrivo, nel senso che contiene dati non coerenti.
Esempio semplice: diciamo che il DB di un negozio in linea tiene
per ogni cliente la cifra che quel cliente ha a disposizione in
quanto prepagata (ad esempio Amazon lo fa cosi` da permettere di
fare "regali in libri" senza scegliere esattamente quali libri,
ma lasciando la scelta al destinatario del regalo).  In una
operazione di trasferimento di EUR 10 dal conto del cliente A a
quello del cliente B (A sta regalando 10 Euro a B) devo togliere
10.00 al conto di A e aggiungere 10.00 al conto di B.  Se sono
due operazioni separate, PROBLEMA: cosa succede se allo stesso
tempo sta girando la "replicazione database" ed essa copia la
cifra del conto di A, e quella del conto di B, "nel bel mezzo"
del trasferimento?  Risposta: i conti non tornano piu`.  Questo
si intende per "database corrotto".
Soluzione: le transazioni.  Ogni operazione sul DB che si
compone di molteplici operazioni piu` elementari deve venire
"incapsulata" in una transazione, con le famose caratteristiche
dettate dalla sigla ACID: Atomica, Coerente, Isolata, Durevole.
In particolare "Atomica" riguarda le transazioni che modificano
il DB: o TUTTE le varie modifiche compiute dalla transazione
sono durevoli sul db, o NESSUNA (transazione fallita); l'importante
(e l'esempio del trasferimento di fondi mostra perche`) e` che
_non sia materialmente possibile_ che l'insieme delle modifiche
sia "un po' applicato e un po' no".
Per la replica di un DB su di un altro devi considerare i due
lati separatamente.  Per quello che stai solo leggendo la cosa
importante e` la coerenza (e l'isolamento), per quello che stai
solo scrivendo l'atomicita` (e la durevolezza, cioe` i dati
scritti devono venire effettivamente salvati:-).  In pratica
ti serve una transazione da una parte e una dall'altra.  Puo`
darsi (a seconda la mole di dati in gioco) che questo tipo in
particolare di operazioni convenga farle non attraverso le
normali interfacce SQL ma attraverso particolari interfacce di
"bulk dump" e "bulk update" che tipicamente i DB prevedono (e
garantiscono ACID e prestazioni particolarmente buone).  Ma
l'importante e` non corrompere mai un DB, quindi, ACID.
Fai _benissimo_ a "voler fare le cose per bene": corrompere un
DB e` bruttissima cosa, fra i peggiori bug che un programma
puo` avere (un crash di un programma e` brutto, ma una
silenziosa corruzione del DB e` peggio -- puo` avere terribili
conseguenze magari anche molto piu` avanti nel tempo).  E le
prestazioni contano, perche` tenere aperta una transazione
troppo a lungo e` problematico (dipende dalla strategia scelta
dal motore del DB per garantire ACID e da quanta altra attivita`
ci sia sul DB, comunque piu` stai in giro con una transazione
aperta piu` e` il rischio che la transazione "vada buca" e la
si debba ricominciare da capo -- meglio che corrompere il DB ma
comunque non divertente:-).  Pero` contano _dopo_ ACID:-).
Quindi, nei tuoi panni, io mi preoccuperei anzitutto di come
garantire atomicita` ecc sia nella lettura dal DB di partenza
sia nella scrittura sul DB d'arrivo; di prestazioni solo in
seconda battuta, anche perche` e` facile che esse siano date
[a] dal motore di DB, [b] da come fai le query (in SQL), [c]
da come ti connetti (locale o in rete, ecc), e solo [d] cioe`
in _quarta_ battuta dalla tua scelta di linguaggio.
Alex