Access ---> MYSQL: qualche piccolo consiglio.

lunedì 02 settembre 2013 - 09.49

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

olmof Profilo | Junior Member

101 messaggi | Data Invio: lun 2 set 2013 - 09:49

Sto cercano di migrare un progetto VB da Access a Mysql e la cosa mi sta creando diversi grattacapi.
Approfittando della gestione "lite" dei database da parte di Access fino ad ora la struttura dei miei database era separata, mi spiego meglio.
Il programma è un gestionale che prevede la possibilità di gestire diverse aziende.
L'organizzazzione degli MDB era fatta attraverso cartelle (quindi una cartella per ogni azienda), per ogni singola azienda avevo un MDB comune per tutti gli anni (contenente le anagrafiche, ecc) e vari MDB per ogni singolo anno gestito (contenente tutte le operazione effettuate nell'anno in essere).
Ora con Mysql la gestione delle cartelle devo abbandonarla. Come mi consigliate di organizzare la struttura dei DB?
Io avevo pensato an un DB con il nome dell'azienda più una serie di DB per i vari anni (quindi molto simile alla gestione attuale). Es. per la gestione dell'azienda Pippo avrei un Db di nome pippo più una serie di Db dal nome pippo_2013, pippo_2014 ecc.
Che ne dite?
Apsetto consigli.
Ciao

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 2 set 2013 - 14:57

>Io avevo pensato an un DB con il nome dell'azienda più una serie
>di DB per i vari anni (quindi molto simile alla gestione attuale).
>Es. per la gestione dell'azienda Pippo avrei un Db di nome pippo
>più una serie di Db dal nome pippo_2013, pippo_2014 ecc.
>Che ne dite?
ora non conosco bene MySQL, ma credo che abbia il concetto di schema..
quindi puoi raggruppare, all'interno dello stesso db, separando gli schema.
Ovvio che questo ti creerebbe problemi di deploy (nel senso che isolare un cliente da un altro non è semplice poi) però è una possibilità.
Dipende poi da che tipo di clienti devi gestire, se sono anche geograficamente dislocati (e non sono clienti interni allo stesso gruppo, per capirci) allora la tua soluzione è la migliore a mio avviso.
Per la gestione degli anni invece è un discorso a parte, abbastanza profondo. E cambia molto in base ai seguenti parametri:
- periodo di storicizzazione
- fruibilità del dato
- cosa devi fare con quei dati

ci sono varie soluzioni, ma con MySQL sono un po' a corto di esperienza diretta.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

renarig Profilo | Expert

517 messaggi | Data Invio: mar 3 set 2013 - 11:25

>L'organizzazzione degli MDB era fatta attraverso cartelle
>(quindi una cartella per ogni azienda)
Provo a lanciare un' alternativa ( certamente laboriosa da realizzare )

Unico DB e uniche tabelle
Aggiungi una Tabella "Aziende" con un campo "NomeAzi" ( Key primaria)
In ogniuna delle altre tabelle aggiungi 1 campo "RefNomeAzi" ( Key Esterna su "Aziende.NomeAzi" )

Modifichi la applicazione in modo che al LogIn si DEBBA selezionare 1 "NomeAzi" dalla tabella "Aziende"

Ogni nuovo record deve avere il nome della sua Azienda al campo "RefNomeAzi"
Ogni query deve essere filtrata sulla "RefNomeAzi"

Questa tipologia che a me piace la ho gia vista in diversi DB contabili usati dai commercialisti
che gestiscono molte piccole aziende .....

.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 3 set 2013 - 13:05

>Unico DB e uniche tabelle
>Aggiungi una Tabella "Aziende" con un campo "NomeAzi" ( Key primaria)
>In ogniuna delle altre tabelle aggiungi 1 campo "RefNomeAzi"
>( Key Esterna su "Aziende.NomeAzi" )
ho trovato tanti gestionali che oltre a questa soluzione hanno seguito anche quella di dare un prefisso alle tabelle TEMPLATE per poi creare una nuova struttura con replace di un placeholder per ogni azienda.
Il problema sta nel capire se i clienti sono dislocati e se devono avere tanti dati e tante performance. Quindi forse è meglio non centralizzare il comportamento nei dati, perchè forse il disaccoppiamento successivo (e soprattutto le customizzazioni per cliente) risulterebbe piuttosto macchinoso e a volte anche irrealizzabile.
Non trovi?

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

olmof Profilo | Junior Member

101 messaggi | Data Invio: mar 3 set 2013 - 18:47

renarig
E' sicuramente una possibilità che però ho sempre scartato per i motivi già indicati da alx_81.
Sw per commercialisti che utilizzano questa soluzione non ne ho mai visti e, soprattutto per le loro esigenze, mi sembra estremamente rischiosa.
Comunque grazie ogni consiglio è sempre prezioso.

renarig Profilo | Expert

517 messaggi | Data Invio: mer 4 set 2013 - 06:18

>... Quindi forse è meglio non
>centralizzare il comportamento nei dati, perchè forse il disaccoppiamento
>successivo (e soprattutto le customizzazioni per cliente) risulterebbe
>piuttosto macchinoso e a volte anche irrealizzabile.
>Non trovi?
E' vero

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 4 set 2013 - 09:32

>E' vero

Sinceramente la discussione è tra le più varie ed interessanti in ambito di modellazione. Quindi non c'è una soluzione.. Come sempre c'è la soluzione adatta all'esigenza

Detto questo, il punto focale a mio avviso è come devono essere gestiti i clienti in termini di "configurazione aziendale".
Mi spiego.. la domanda che mi porrei è: "che azienda sono io e che tipo di rapporto voglio col cliente?".
Rispondendo a questa domanda scremo le cose che non posso proprio fare. Ad esempio.. un server a cliente? Bene.. non posso modellare nello stesso database. Oppure, I clienti possono condividere lo stesso server ma voglio i permessi iper fini e customizzabili? Bene, allora meglio comunque avere database/istanze diverse. E ancora, che costi di licenza posso affrontare o far affrontare al cliente? Bassi? Bene.. ridurre al massimo le istanze e quindi condividere tutto in un punto. E se vogliamo continuare ancora.. Le customizzazioni sono distribuibili per tutti i clienti oppure posso rilasciare pacchetti solo ad uno? In un caso posso "unire" prendendomi il rischio di far fatica a disaccoppiare in futuro e nell'altro devo per forza verticalizzare per cliente.
Poi, dal modello di distribuzione.. passi alle performance. Che succede se un indice si comporta bene per un cliente ma non per l'altro (vedi numero righe considerate e traffico, deadlock, lock, ecc)? Che potenzialmente una correzione dà benefici solo ad un cliente e potenzialmente l'altro cliente potrebbe anche perderci..
E sono stato mooooolto stringato. Ci sarebbe da investire almeno una sessione di una settimana in queste cose

Anzi, di solito nei corsi che tengo non posso nemmeno dilungarmi altrimenti non ci stiamo

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

olmof Profilo | Junior Member

101 messaggi | Data Invio: mer 4 set 2013 - 12:15

Nel mio caso specifico ogni cliente ha la propria installazione (eventualmente personalizzata).
Ogni singolo cliente ha la possibilità di gestire diverse aziende (in teoria illimitate): è qui che nascono i dubbi sulla struttura del database.
Il mio progetto originale (mi pare fosse il 1994) era scritto in VB 4 ed utlizzava access (al tempo gli strumenti erano quelli).
In questi anni ha retto abbstanza bene con poortune modifiche ed integrazioni.
Ora però è arrivato il momento di cambiare completamente a costo di riscriverlo (ed è quello che voglio fare).
L'esperienza di questi anni mi ha portato a riconsiderare la struttura interna delle varie tabelle, ma per quanto riguarda l'idea dei Db veri e propri non ho trovato giustificazioni per modificarla: cioè ogni azienda gestita (da ogni singolo cliente) ha 1 database generale più 1 database per ogni anno gestito.
Ciao

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 5 set 2013 - 18:09

>Nel mio caso specifico ogni cliente ha la propria installazione (eventualmente personalizzata).
e questo già obbliga un certo livello di separazione, anche dei dati stessi.. non solo delle strutture.

>Ogni singolo cliente ha la possibilità di gestire diverse aziende (in teoria illimitate): è qui che nascono i dubbi sulla struttura del database.
Ecco.. questo vuol dire che i tuoi clienti sono tipo delle "holding" che contengono a loro volta n aziende. In questo caso, o dai al cliente un template da cui lui poi eredita una struttura custom per ogni azienda (gli dai il db centrale di template e un app che con pochi parametri crea un db per azienda), oppure dai al cliente un'installazione per sottocliente. Ma i clienti vorranno eseguire le cose su un server loro oppure puoi anche erogare servizio?

Comunque se hai già in testa una soluzione vincente e se sai che è perfetta per i tuoi scopi, cambia tecnologia ma non cambiare quanto è già comodo per te..
Chiaro è che qualunque sia la strada che seguirai, un giorno avrai problemi di performance o di separazione.. quindi pensa bene alle varie procedure di isolamento, svecchiamento, manutenzione e quant'altro..
ciao
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

olmof Profilo | Junior Member

101 messaggi | Data Invio: ven 6 set 2013 - 07:23

A me sembra che la mia soluzione sia valida, però mi piace sempre confrontarmi con altri sicuramente più esperti di me.
In effetti prima avevo un db di riferimento che veniva utilizzato per l'installazione di ogni nuova azienda presso ogni installazione: Es. installazione dal cliente pippo: deve gestire una nuova azienda, faccio una copia del MDB di riferimento ed ero a posto.
Però è da qui che nasce il mio secondo post: come faccio questa operazione in ambiente MYSQL.
Probabilmente seguirò la strada di crearlo ex novo ogni volta che ne ho bisogno.

Grazie comunque per tutto.
Ciao

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 6 set 2013 - 10:10

>A me sembra che la mia soluzione sia valida, però mi piace sempre
>confrontarmi con altri sicuramente più esperti di me.
>In effetti prima avevo un db di riferimento che veniva utilizzato
>per l'installazione di ogni nuova azienda presso ogni installazione:
>Es. installazione dal cliente pippo: deve gestire una nuova azienda,
>faccio una copia del MDB di riferimento ed ero a posto.
>Però è da qui che nasce il mio secondo post: come faccio questa
>operazione in ambiente MYSQL.
>Probabilmente seguirò la strada di crearlo ex novo ogni volta che ne ho bisogno.
sinceramente con mySQL sono a bocca asciutta, però immagino che se hai stored procedure e il suo linguaggio di programmabilità non dovrebbe essere così diverso, anzi.
Tuttavia, la scelta di mySQL è solo per il prezzo? Hai considerato anche la curva di apprendimento e i costi che dovrai affrontare per sviluppi comunque diversi?
Hai provato a pensare anche alla parte di Azure?

>Grazie comunque per tutto.
è stata una discussione interessante, grazie a te

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !