MySQL: consiglio struttura e fk su database diversi

[aasmdaa]

Ho 3 gestionali installati in 3 diverse sedi con relativi database access. Ora devo portare il tutto su un singolo server.

dato che devo per forza mantenere separati i database per sedi (a causa di indici e fk) ho preparato 3 nuovi database in MySQL.

Alcune di queste tabelle (le anagrafiche) sono però identiche per tutti e 3 i database e le vorrei riunire in una sola.

Il problema è relativo alle fk, dato che non se sia possibile/corretto fare le fk su database diversi.

Mi spiego con l'esempio:

SITUAZIONE ATTUALE
db_azienda_milano
db_azienda_torino
db_azienda_venezia

questi 3 hanno in comune 10 tabelle di anagrafiche

io vorrei portare il tutto a

db_azienda (che conterrà le anagrafiche comuni)
db_azienda_milano
db_azienda_torino
db_azienda_venezia

questo perchè altrimenti se modifico un operatore in un'anagrafica dovrei riportare la modifica su tutti i database (che andranno ad aumentare).

Cosa dite ha senso ed è corretta/fattibile questa soluzione?

grazie
ciao

[123delphi321]

le fk funzionano all'interno dello stesso database.

credo che dovresti unire tutti e 3 i database in un unico database e quindi avere una unica tabella anagrafica

[aasmdaa]

unirli non è fattibile in quanto sono già esistenti e ci sono un gran numero di indici che sarebbero ripetuti. inoltre si sommerrebbero anche i dati allungando notevolmente la tabella (quindi rallentamenti).

chiaro che se partissi con un progetto vuoto aggiungerei semplicemente una discriminante per sede nelle tabelle, ma non è questa la situazione.

[deleted_29]

1) federated (ma è ormai obsoleto e deprecato)
2) ti fai i "tuoi" trigger per le FK
http://dev.mysql.com/tech-resources/...eign-keys.html
3) non mi è chiarissimo quale sia il problema: nei trigger puoi indicare il nome del database.
Il vero problema è evitare una modifica circolare

Per inciso a mio parere non ha il minimo senso tenersi un paciugo del genere, da ogni punto di vista, anche delle prestazioni.
Nel caso (dubito ti serva) ti basta partizionare sul campo discriminante

[aasmdaa]

x franzauker: per cui anche tu consigli di spostare tutti i dati in un unico database?

io vedevo dei vantaggi nel tenere 3 database separati:

1) prestazioni: alla ricerca ad esempio di un cliente scorro solo le righe di quel database e non la somma dei 3 (ad es. ho circa 3000 clienti per database)
2) nel caso di problematiche in un database gli altri 2 continuano a lavorare, mentre se ne ho uno unico blocco 3 sedi
3) il lavoro ed il rischio di fare macello portando i dati in un'unico database (non mi è chiaro infatto come mantenere l'integrità referenziale di tabelle uguali con uguali campi primari)

[deleted_29]

Originariamente inviato da aasmdaa
x franzauker: per cui anche tu consigli di spostare tutti i dati in un unico database?

Sì

io vedevo dei vantaggi nel tenere 3 database separati:

1) prestazioni: alla ricerca ad esempio di un cliente scorro solo le righe di quel database e non la somma dei 3 (ad es. ho circa 3000 clienti per database)

E' un non-vantaggio, se usi mysql da 5.1 in su puoi partizionare le tabelle.
E dalla 5.6 puoi addirittura indicare nelle query le partizioni da usare "manualmente"

2) nel caso di problematiche in un database gli altri 2 continuano a lavorare, mentre se ne ho uno unico blocco 3 sedi

Ecco perchè hanno inventato la replicazione

3) il lavoro ed il rischio di fare macello portando i dati in un'unico database (non mi è chiaro infatto come mantenere l'integrità referenziale di tabelle uguali con uguali campi primari)

non ti so dire, non uso praticamente mai integrità referenziale gestita dal db.
tantomeno database diversi per il medesimo applicativo (marchio le righe col polo amministrativo). cosa non strettamente indispensabile per mysql (cui basta preporre il nome db ai campi), ma estremamente utile per gli RDBMS non così "aperti"

O meglio ti saprei dire se conoscessi che db è e che programmi usi, ma ritengo che te la possa cavare con un po' di... ehm... bestemmie

Perchè difficilmente potrai avere botte piena e moglie ubriaca

[aasmdaa]

Ma quante ne sai?

Ho studiato il partizionamento (che ovviamente non conoscevo) ed ok. Se non ho capito male potrei ad esempio aggiungere un campo discriminante nell'anagrafica riguardante la sede e poi partizionare sfruttando appunto questo campo.
Non ho invece capito se il partizionamento lo posso fare solo a database vuoto in fase di creazione oppure anche con dati all'interno.

Quello però che non ho capito è:

non ti so dire, non uso praticamente mai integrità referenziale gestita dal db.

e come fai?

tantomeno database diversi per il medesimo applicativo (marchio le righe col polo amministrativo)

ho cercato polo amministrativo ma non ho capito cosa sia.

Infine non mi è chiaro come, utilizzando i trigger ed avendo utilizzato l'integrità referenziale del db, quale potrebbe essere la soluzione per fare il merge dei 3 database senza incasinare tutti gli id e fk.

[deleted_29]

Originariamente inviato da aasmdaa
Ma quante ne sai?

In realtà sono un filosofo esperto di gatti

Ho studiato il partizionamento (che ovviamente non conoscevo) ed ok. Se non ho capito male potrei ad esempio aggiungere un campo discriminante nell'anagrafica riguardante la sede e poi partizionare sfruttando appunto questo campo.

Campo discriminante= polo amministrativo.
Attenzione però: il partizionamento non è magico, rischi di avere prestazioni PIU' BASSE perchè dipende da una caterva di circostanze (che volendo si possono approfondire).
In versione superbreve è: se le righe son poche costa di più gestire il partizionamento che non farlo.
E così se ci son query che spesso NON comprendono il campo discriminante.

Come si fa a decidere? E' più semplice di quanto si pensi.
Si prova => si misura [questa è l'elemento fondamentale] => si decide.

Prendere decisioni su ottimizzazioni "teoriche" non è auspicabile.
Prima misuri, poi fai.

Non ho invece capito se il partizionamento lo posso fare solo a database vuoto in fase di creazione oppure anche con dati all'interno.

Anche con dati dentro

e come fai?

Li gestisco lato-applicazione, ovviamente.
Tra l'altro fino a pochissimo (per modo di dire) tempo fa le FK neppure esistevano, in mysql.

Infine non mi è chiaro come, utilizzando i trigger ed avendo utilizzato l'integrità referenziale del db, quale potrebbe essere la soluzione per fare il merge dei 3 database senza incasinare tutti gli id e fk.

Il problema risiede nella "circolarità" dei trigger.
L'integrità referenziale non è altro che una serie di "trigger" che occultamente vengono attivati da mysql, niente di magico.

Puoi creare un trigger (in realtà "più trigger") sulla tabella1 che viene azionato quando inserisci, modifichi o cancelli "qualcosa", facendolo "ricopiare" sulla tabella2, tabella3... tabella N-esima, con una gestione delle FK "a mano" (cascading delete e quello che vuoi).

Ma il problema sorge nel momento in cui vuoi fare sì che modificando la tabella2 cambi la 1.
Un trigger speculare non farebbe altro che far entrare in loop.

Cambi la tabella 1 => si attiva il trigger sulla tabella 1 => ti cambia i dati nella tabella 2 => si attiva il trigger sulla tabella 2 => ti va a cambiare i dati nella tabella 1 =>...

Francamente non so cosa succeda in un caso del genere, immagino niente di buono, ma non posso confermarlo.

Se hai voglia => prova
---
Posso dirti cosa farei io (anche se non so nulla di questo programma)

1) niente mysql, bensì mariadb
2) se sono anagrafiche le fonderei tutte, col polo amministrativo ed eventualmente tabella partizionata
3) se son usate per ricerche userei direttamente sphinx (facilmente integrabile in mariadb, più che in mysql)

[aasmdaa]

Ok tutto abbastanza chiaro. Mi cimento nei lavori e vedo di usare la strada migliore.

grazie per tutte le dritte.