Newsgroup: it.comp.software.database
Titolo: Da Filemaker a MySQL...e ritorno : )

Ciao a tutti,
Prima di tutto una disclosure: il post seguente non vuole dare adito a
nessun flame, ma una discussione costruttiva mi farebbe piacere : ).
La mia conocsenza sui Database e' trascurabile, ma in crescita, e' un
mondo che m'interessa, e di cui vorrei conoscere di piu', quindi
abbiate pazienza se le mie domande appariranno troppo banali.
Sto cercando di convertire un Database filemaker (su FM server 9,
windows server 2003) a MySQL, con il proposito di tenerli entrambi.
Sia FM che MySQL soddisfano parzialmente tutto quello che cerco in un
database...il primo la facilita' d'uso, l'immediatezza, ed anche
l'estetica se vogliamo, il secondo la robustezza e la velocita'.
L'operazione di conversione e' a buon punto, faccio tutto via .csv, e
contavo di usare SQLyog per aggiornare in tempo reale MySQL da FM (che
rimarrebbe comunque l'interfaccia utente principale) in seguito ad
ogni modifica su quest'ultimo, via ODBC.
Rimangono da chiarire un paio di aspetti essenziali pero' :
1) Primary e Foreign Key nel mondo MySQL. Quando ho disegnato il
database in FM, le mie conoscenze erano pressoche' nulle (adesso sono
poco piu' che nulle) cosi' il database (che e' un DB per ricerca
clinica) e' strutturato in modo da avere una tabella principale
(demografica pazienti) e tutte le altre tabelle (essenzialemente esami
e terapia) collegate a questa direttamente tramite la condivisione di
un'unica chiave primaria. In altre parole, ho PazID su Demografica, e
la stessa chiave su tutte le altre tabelle, che si relazionano fra
loro e con la tabella principale appunto tramite PazID.
Schematicamente, nella condizione attuale abbiamo:
1) Tab. Demografica : PazID, No altre chiavi
2) Tab Ecografia: PazID, no altre chiavi
3) Tab Risonanza: PazID, no altre chiavi
ecc...
Fin qui tutto bene, il database funge perfettamente, mai avuto un
problema. Nei vari testi o articoli letti pero' tutti aggiungono una
chiave primaria per tabella ed utlizzano PazID come Foreign Key. Ossia
avremmo
1) Tab Demografica: PazID, primaria ma anche EcoID (foreign) e RisID
(foreign)
2) Tab Ecografia: EcoID (primaria), PazID (foreign) e RisID (foreign)
3) Tab Risonanza: RisID (primaria), PazID(foregn) e EcoID (foreign)
ecc...
Questa struttura potrei riportarla in FM in pochi minuti, ma la
domanda e': e' davvero necessario nel mio caso, o posso lasciare le
cose come stanno ? Se pensate sia necessario, mi spiegate anche
perche' (magari con un esempio) ? Se invece pensate che non sia
necessario, mi dite in quale scenario diventa essenziale avere un
struttura basata su primary/foreign key (pura curiosita') ?
Ed arriviamo cosi' alla seconda domanda:
2) Come si creano le relazioni su MySQL ? Basta un  ALTER TABLE che
dica al server cosa usare come chiave primaria in tutte le tabelle
(ossia PazID, assicurandosi che tale chiave sia uguale in tutte) o
devo fare qualcos'altro ?
Se invece ho la necessita' di aggiungere anche le foreign keys (ossia
differenziare fra primary e foreign) come lo faccio in MySQL ?
infine
3) Qualcuno per caso si trova nella rara situazione di dovere
sincronizzare FM e MySQL in tempo reale (beh una latenza di un'ora
andrebbe piu' che bene) ? Che soluzione avete adottato ?
Grazie per avere letto tutto, spero potrete darmi una mano,
Diego

 andrebbe piu' che bene) ? Che soluzione avete adottato ?
Schedulazione tramite cron e script di aggiornamento.
Poi le modalità possono variare a seconda delle casistiche, ad esempio 
se le modifiche possono essere effettuate su entrambi i db o solo su uno.
Ciao,
Paolo

 struttura basata su primary/foreign key (pura curiosita') ?
- ogni volta che si necessita della presenza di una riga
indispensabile per l'integrita` dei dati (es. fattura/righe fattura)
- ogni volta che una business rule la richiede (es. ogni esame
deve riferirsi ad un paziente gia` censito)
bye 

 Paolo
Diego

 base ai cambiamenti su FM.
Purtroppo qualcosa che esporti da FM e importi in MySQL lo devi usare.
O trovi qualcosa di pronto o ti tocca studiarti un qualche linguaggio di 
programmazione (es. con Python è facile interfacciarsi sia con MySQL che 
con FM e il linguaggio è semplice da imparare).
Ciao,
Paolo

 andrebbe piu' che bene) ? Che soluzione avete adottato ?
In Access e` possibile utilizzare la funzione "Collega tabelle", che
permette di utilizzare tabelle presenti su di una fonte esterna,
definita solitamente come fonte ODBC (dovrebbe essere possibile
utilizzare anche un driver ADO, ma non ci metterei la mano sul fuoco).
Filemaker puo` fare la stessa cosa, ovvero puo` connettersi ad un
database esterno tramite ODBC? Secondo il sito di FileMaker e` possibile
connettere FileMaker 9 Server ad una sorgente esterna (tra cui MySQL),
mentre nella versione FileMaker Server 9 Advanced e` possibile
gestire connessioni via ODBC. Personalmente utiizzerei questo metodo,
ottenendo quindi che FileMaker faccia da frontend, mentre MySQL farebbe
da backend. Inoltre, prima di mettere tutto in produzione,
verificherei che versione di FileMaker e` in mio possesso, e se ho la
Advanced, proverei ad utilizzare come fonte ODBC (e quindi come backend)
PostgreSQL o Firebird
Enrico

On Mar 6, 3:51 pm, Enrico 'Henryx' Bianchi

Innanzitutto grazie per i consigli.
In effetti avevo pensato ad una soluzione del genere, e FM 9 (ho un
server sdv su win)
e' pronto per entrambe le soluzioni (accedere alle tabelle MySQL
direttamente, o via ODBC)
ma diverse persone sui gruppi dedicati al database in questione mi
hanno parlato della lentezza
di FM nell'accesso/scrittura a tabelle MySQL usando ESS (External SQL
services).
Rimane l'opzione ODBC, pero' la stessa FM sconsiglia caldamente di
usare MySQL come backend
definitivo per FM (tutto viene rallentato). Probabilmente comunque
provero' in un secondo momento, avendo per adesso
risolto nel seguente modo:
1) Ho normalizzato finalmente il DB (grazie Paolo per i consigli e le
pettinate !)
2) Convertito tutto il DB (600 campi su 9 tabelle, ~ 1000 records per
tabella) in MySQL con SQLyog (versione a pagamento,
costa 50 $ ma li vale tutti). A proposito, per la conversione ho
provato diversi progs, fra cui anche quelli di EMS, ed MySQL Migration
tool,
ma nulla funziona tanto bene ed in modo cosi' immediato come SQLyog.
3) Come detto, l'obiettivo era di tenere entrambi i database attivi,
con una sincronizzazione one-way per adesso (nuovi records su FM,
MySQL si aggiorna da li'), quindi dopo la migrazione mi sono trovato
nella situazione di dover trovare un modo per sincronizzare MySQL
partendo
da FM, ed il problema e' che SQLyog prevede si la sincronizzazione
(sia one che two way) ma solo da MySQL a MySQL, ODBC non e'
supportato.
La soluzione, abbastanza artificiosa, ma funzionale per quanto mi
consta e'  uno scheduling notturno di converisone del DB da FM a MySQL
con la creazione
di un database temporaneo MySQL, e successiva sincronizzazione fra
temporaneo e definitivo sempre in automatico tramite SQLyog.
Sicuramente questa non e' la soluzione ideale, ma considerate le
dimensioni del DB (presenti e futuribili) ed i tempi attuali
(migrazione in 15 sec.
sincronizzazione in 25) e considerando che viene fatto tutto di notte,
per il momento sono soddisfatto.
Ho impiegato due giorni, trascurando i miei obblighi di medico, ma ho
imparato tantissimo , grazie a tutti ed in particolare a Paolo per la
pazienza
(virtu' abbastanza rara nella categoria degli informatici, ed
inversamente proporzionale alla competenza)
Diego

 inversamente proporzionale alla competenza)
Mi stai dando dell'incompetente?!
;)


Beh, tu sei la classica eccezione : )

 informatici, ed inversamente proporzionale alla competenza)
Mah!
Questa infelice frase e` doppiamente ingenerosa: sia nei confronti
dei tanti "normali" utenti che mettono a disposizione il loro
tempo sulla rete, i quali non credo siano contenti di essere
etichettati a priori come incompetenti, sia nei confronti dei tanti
guru di fama mondiale che si lasciano avvicinare in rete.
Ma soprattutto, la frase e` un clamoroso falso! In rete trovi
tonnellate di documenti di ogni livello, oltre agli autori
dei piu` famosi libri sui database, contattabili sui newsgroup
o sui rispettivi blog/siti o per email. 

 inversamente proporzionale alla competenza)
Probabilmente questa tua frase voleva essere un complimento rivolto alle
persone del gruppo che ti hanno aiutato, ma considerando la natura
ambigua delle parole che hai usato, ti consiglierei di non ripeterla in
futuro
Enrico

On Mar 7, 5:06 pm, Enrico 'Henryx' Bianchi


Scusami Enrico, in effetti si, voleva essere un complimento
a tutte le persone estremamente competenti (come te) che
mi hanno dato una mano, ma mi rendo conto dell'ambiguita' della
frase, che evitero' in futuro.
Grazie ancora,
Diego


Interessante, hai ritenuto opportuno spendere piu' parole (e tempo)
per puntualizzare la mia ingenerosita' oggi che non spiegare bene
cosa volessi dire a proposito del mio problema qualche giorno fa (vedi
sopra).
Ovviamente la mia frase non era rivolta agli utenti "normali" i quali
non fanno gli informatici
per vivere (come me del resto) e che, nella mia esperienza, sono
sempre
disponibilissimi, mettendo a disposizione tempo ed energie per dare
una mano.
Voleva essere invece uno spunto di riflessione per tutti coloro che
alla domanda
"come posso risolvere il problema ?" rispondono "pensaci su, ecco un
utile esercizio...".
Ovviamente parto dal pressuposto che prima di postare si sia fatta una
ricerca accurata
sui documenti liberamente reperibili in rete (che sono in effetti
tonnellate) e che le domande
fatte prevedano un periodo di studio del problema, al quale purtroppo
non sempre
si riesce a dare soluzione. Questo chiaramente non ha nulla a che fare
con il "volere
la pappa pronta", anche se spesso cosi' viene inteso. Pensa cosa
succederebbe se a coloro
che postassero su it.scienza.medicina per un problema di salute,
venisse risposto che
la domanda e' banale e non ha senso, dal momento che la rete e' piena
di documenti approfonditi sull'argomento (cosa vera
per tutte le malattie esistenti). In effetti, raramente, succede anche
questo, una cosa estremamente triste
secondo me.
Penso che chi posti qui ( o in generale sui gruppi tecnici) lo fa
perche' non sa piu' dove sbattere la testa
e vorrebbe avere un parere, ma soprattutto un sostegno paziente. Credo
che quando sai far bene
qualcosa, il tempo che impieghi a spiegare come fai non deve
necessariamente prendere dieci pagine e due ore del tuo tempo.
Ed in effetti sia Paolo che Enrico mi hanno aiutato in un paio di
post, con risposte semplici ed esaurienti.
In ogni caso, il mio ringraziamento include anche te, ho imparato
molto anche dalla tua risposta,
anche se non inerentemente al mio problema.
Diego

 (vedi sopra).
Non prendere personalmente i miei commenti, dato che non lo sono
quasi mai. Non avevo detto niente di te, ma del concetto
espresso dalla frase, il che e` parecchio differente.
D'altronde, anche io trovo "interessante" aprire un thread
dicendo di non volere fare flame, e concludere sparando
una cannonata... o no? ;-)
ciao 


Touche' : )
in verita', il mio invece voleva essere un commento personale, diretto
non a te soltanto naturalmente,
ma a tutti coloro che rispondono a volte troppo sbrigativamente, qui
ed altrove.
Spero comunque che siamo ancora sul livello della "discussione
costruttiva" e di non essere arrivati al flame,
cosa che in 13 anni di Usenet sono riuscito miracolosamente ad
evitare.
Mi rendo conto soltanto adesso che con la mia frase ho sparato una
cannonata, in effetti
voleva essere semplicemente un invito alla riflessione, ma l'ironia e'
a volte difficile da trasmettere,
non volevo in nessun caso essere offensivo (quello si, non lo sono
quasi mai).
Spero in futuro potremo avere scambi meno accesi ed ancora piu'
costruttivi,
Diego

 anni di Usenet sono riuscito miracolosamente ad evitare.
Per me assolutamente nessun problema. Io ho le filosofie orientali
dalla mia parte :-)) 

 prova a vedere chi scrive di piu`...
Io e te, con incursioni di alcuni tizi strani e dei bot? :)
Enrico