Migrazione Access --> Oracle o SQLServer
Rafunk
solitamente), e oltre ad augurare buon 2006 a tutti ho una questione da porre.
Ho un'applicazione basata su DB Access che dovrei migrare ad un DBMS più "serio"
(Oracle o SQLServer).
Tralasciando le problematiche relative ai tipi, ai diversi dialetti SQL etc..,
ho una necessità particolare.
Per motivi legati alle prestazioni ed alla robustezza, i dati sono suddivisi in
svariati MDB (potenzialmente anche 10000), tutti strutturati nello stesso modo
con una dozzina di tabelle ciascuno. Ogni MDB è relativo ad una persona (il nome
corrisponde all'ID) e ne contiene i dati "storici" gestiti dall'applicazione.
(Esiste poi un ulteriore MDB, unico, con una tabella che elenca i dati
anagrafici di ciascuna persona.)
Qual è la strategia ottimale per trasportare una struttura così fatta sotto
Oracle (o SQLServer)?
a) Proliferare le tabelle, aggiungendo a ciascuna un suffisso che denoti la
persona a cui si riferisce (un ID)
b) Conglobare tutte le tabelle omonime in un'unica tabellona (potenzialmente
anche di centinaia di milioni di record), con un indice clustered sull'ID
c) Altre idee?
Aggiungo che non mi ritengo propriamente un esperto in questo settore...
Grazie in anticipo
Bye
Raf
matteooooo
Rafunk wrote:
> c) Altre idee?
>
Lasciare inalterata la struttura aggiungendo per ogni tabella delle
dodici che costituiscono la struttura attuale una chiave con il
riferimento della persona e quindi riversare tutti i dati dei tuoi DB
Access.
Rafunk
news:1136210915.4...@g49g2000cwa.googlegroups.com...
Forse mi sono spiegato male, ma questa č esattamente la mia idea b ;-)
Ma le performances poi? Alcune di queste tabellone andranno a contenere decine
di migliaia di righe per persona, con un numero complessivo di persone
dell'ordine di 10000. Č sufficiente un indice clustered o ci sono idee piů
"furbe"?
Grazie
Ciao
Raf
matteooooo
Rafunk wrote:
> Ma le performances poi? Alcune di queste tabellone andranno a contenere decine
> di migliaia di righe per persona, con un numero complessivo di persone
> dell'ordine di 10000. È sufficiente un indice clustered o ci sono idee più
> "furbe"?
Con una macchina decente e tabelle ben organizzate tabelle di queste
dimensioni non sono un problema.
Più che un indice clustered sarebbero da prendere in considerazione le
partition table(su Oracle) ma molto dipende anche da che tipo di dati
contengono le tabelle e come ci accedi.
Ciao
Matteo
Fabrizio Magni
Ciao,
mi intrometto brevemente nella discussione senza toccare il lato tecnico.
Il partitioning, almeno per oracle, e' un'opzione particolarmente
costosa. Implica l'acquisto di licenze enterprise e il pagamento
dell'opzione stessa (da pagare a parte) che aumenta il costo totale
delle licenze del 50%.
Non conosco invece la situazione per sql server 2005 ma sarei
interressato a saperne di piu' se qualcuno ha informazioni commerciali
al riguardo.
Buona serata
--
Fabrizio Magni
replace mycontinent with europe
Rafunk
I dati più "popolosi" sono essenzialmente transazioni acquisite da
terminali-orologio (o di produzione) e i dati sono tipicamente data/ora, verso,
eventuale codice digitato.
Prevalentemente vengono acceduti in sola lettura, selezionandoli per range
temporali da "elaborare".
Vedrò di documentarmi un po' sulle PT di Oracle...
Ciao e grazie
Raf
Rafunk
news:43b95b27$0$73887$892e...@authen.yellow.readfreenews.net...
> > Con una macchina decente e tabelle ben organizzate tabelle di queste
> > dimensioni non sono un problema.
> > Più che un indice clustered sarebbero da prendere in considerazione le
> > partition table(su Oracle) ma molto dipende anche da che tipo di dati
> > contengono le tabelle e come ci accedi.
> >
>
> Ciao,
> mi intrometto brevemente nella discussione senza toccare il lato tecnico.
>
> Il partitioning, almeno per oracle, e' un'opzione particolarmente
> costosa. Implica l'acquisto di licenze enterprise e il pagamento
> dell'opzione stessa (da pagare a parte) che aumenta il costo totale
> delle licenze del 50%.
Nel mio caso non sarebbe un problema in quanto i potenziali clienti che hanno
richiesto il porting hanno già licenze enterprise di Oracle...
Bye
Raf
Fabrizio Magni
>
> Nel mio caso non sarebbe un problema in quanto i potenziali clienti che hanno
> richiesto il porting hanno già licenze enterprise di Oracle...
>
Ok, ma dovranno pagare anche il partitioning che costera' il 50% del
valore delle licenze enterprise edition.
A costi di listino, per un server quadriprocessore, si passa da circa
160.000 euro a 240.000.
in piu' il tuo potenziale cliente dovra' pagare il 22% di quella cifra
ogni anno (piu' l'IVA) per il supporto e la manutenzione.
Se il cliente non ne vede i benefici potrebbe fare storie.
Personalmente se qualcuno mi mostrasse una soluzione del genere non
sarei disposto ad accettare i costi aggiuntivi per dei benefici non
sempre tangibili.
Solitamente (praticamente sempre) io sono il cliente... e i costi e la
manutenibilita' del sistema sono tra le cose che maggiormente guardo
mentre valuto una soluzione che mi viene proposta da una societa' di
servizi.
Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
suonare il campanello d'allarme e magari votare contro il progetto.
Ciao
Rafunk
>
> >
> > Nel mio caso non sarebbe un problema in quanto i potenziali clienti che
hanno
> > richiesto il porting hanno già licenze enterprise di Oracle...
> >
>
> Ok, ma dovranno pagare anche il partitioning che costera' il 50% del
> valore delle licenze enterprise edition.
> A costi di listino, per un server quadriprocessore, si passa da circa
> 160.000 euro a 240.000.
>
> in piu' il tuo potenziale cliente dovra' pagare il 22% di quella cifra
> ogni anno (piu' l'IVA) per il supporto e la manutenzione.
>
> Se il cliente non ne vede i benefici potrebbe fare storie.
Non sono sicuro, ma essendo il cliente un ente pubblico a livello regionale non
credo che abbia di questi problemi.
Comunque mi informerò.
> Personalmente se qualcuno mi mostrasse una soluzione del genere non
> sarei disposto ad accettare i costi aggiuntivi per dei benefici non
> sempre tangibili.
>
> Solitamente (praticamente sempre) io sono il cliente... e i costi e la
> manutenibilita' del sistema sono tra le cose che maggiormente guardo
> mentre valuto una soluzione che mi viene proposta da una societa' di
> servizi.
Non fa una piega.
> Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
> suonare il campanello d'allarme e magari votare contro il progetto.
Sono aperto ad ogni alternativa!
Bye
Raf
Fabrizio Magni
>
>>Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
>>suonare il campanello d'allarme e magari votare contro il progetto.
>
>
> Sono aperto ad ogni alternativa!
>
Ciao Rafunk,
non volevo bocciare il partitioning. Volevo solo consigliarti di
proporlo con una serie di motivazioni e tenere aperta la possibilita' di
rinunciarci se necesario (e richiesto dal cliente).
Opinione personale ma: visto che arrivi da access dubito che il tuo sia
un OLTP.
Se stai creando un datamart o l'inizio di un datawarehouse, e non hai
problemi a cambiare il design delle tabelle (come hai fatto intendere)
allora progetta uno star schema.
Cerca materiale di Ralph Kimball a riguardo.
Questa e' un opzione che potrai rivendere ad ogni futuro cliente
(soprattutto nel mondo della "business intelligence") in quanto
indipendente dalla piattaforma.
Una volta che questo e' stato creato allora potrai decidere le strutture
di memorizzazione da usare (come le tabelle partizionate), l'uso di
strutture di accesso come gli indici bitmap o delle materialized view.
Queste ultime dipendono piu' dal RDBMS che stai usando.
Se il tuo cliente non ha grandi competenze allora dovra' sapere che tu
sarai necessario per la manutenzione soprattutto per l'uso di feature
come il partitioning.
Ma considerando il tuo primo post direi che la cosa piu' importante ti
era chiara fin dall'inizio. Il design piu' che le modalita' di accesso
ai dati possono fare la grande differenza.
Rafunk
> Rafunk wrote:
> >
> >>Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
> >>suonare il campanello d'allarme e magari votare contro il progetto.
> >
> >
> > Sono aperto ad ogni alternativa!
> >
>
> Ciao Rafunk,
> non volevo bocciare il partitioning. Volevo solo consigliarti di
> proporlo con una serie di motivazioni e tenere aperta la possibilita' di
> rinunciarci se necesario (e richiesto dal cliente).
>
> Opinione personale ma: visto che arrivi da access dubito che il tuo sia
> un OLTP.
> Se stai creando un datamart o l'inizio di un datawarehouse, e non hai
> problemi a cambiare il design delle tabelle (come hai fatto intendere)
> allora progetta uno star schema.
> Cerca materiale di Ralph Kimball a riguardo.
Grazie per l'indicazione, ma è tutt'altro genere di dati che devo gestire. Come
dicevo in un post precedente, sono transazioni acquisite da
terminali-marcatempo, quindi dati storici di rilevazione presenze/assenze, per
aziende ed enti pubblici di grosse dimensioni (anche 10000 dipendenti).
> Questa e' un opzione che potrai rivendere ad ogni futuro cliente
> (soprattutto nel mondo della "business intelligence") in quanto
> indipendente dalla piattaforma.
>
> Una volta che questo e' stato creato allora potrai decidere le strutture
> di memorizzazione da usare (come le tabelle partizionate), l'uso di
> strutture di accesso come gli indici bitmap o delle materialized view.
> Queste ultime dipendono piu' dal RDBMS che stai usando.
>
> Se il tuo cliente non ha grandi competenze allora dovra' sapere che tu
> sarai necessario per la manutenzione soprattutto per l'uso di feature
> come il partitioning.
Probabilmente il cliente ha abbastanza competenze.
> Ma considerando il tuo primo post direi che la cosa piu' importante ti
> era chiara fin dall'inizio. Il design piu' che le modalita' di accesso
> ai dati possono fare la grande differenza.
Grazie ancora
Ciao
Raf
Enrico 'Henryx' Bianchi
> Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
> suonare il campanello d'allarme e magari votare contro il progetto.
http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html
Probabilmente non sara` al livello di Oracle, ma dovrebbe funzionare.
Inoltre, permetterebbe di risparmiare parecchi soldi, il che non e` male
Henryx
--
Signore e signori! Lo avete letto sui giornali! E ora fremerete d'orrore
osservando con i vostri stessi occhi il piu` raro e tragico degli
scherzi di natura! .. l'uomo medio!
Joker (Batman: the killing joke)
Fabrizio Magni
> On Mon, 02 Jan 2006 20:27:31 +0100, Fabrizio Magni wrote:
>
>
>>Il semplice buttare li' il partitioning e' una di quelle cose che mi fa
>>suonare il campanello d'allarme e magari votare contro il progetto.
>
>
> http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html
>
> Probabilmente non sara` al livello di Oracle, ma dovrebbe funzionare.
> Inoltre, permetterebbe di risparmiare parecchi soldi, il che non e` male
Grazie della dritta Henryx.
Sono veramente a digiuno di postgres.
Probabilmente e' il caso che me lo studi meglio.
Sai come si comporta con grandi moli di dati?