Newsgroup: it.comp.software.database
Titolo: Migrazione Access --> Oracle o SQLServer

Con l'anno nuovo ho pensato bene di esordire in questo NG (bazzico iclvb
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


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.

 ha scritto nel messaggio
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

 "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


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
fabrizi...@mycontinent.com
replace mycontinent with europe

 ha scritto nel messaggio
news:1136216122.5...@z14g2000cwz.googlegroups.com...

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

 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

 
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


 suonare il campanello d'allarme e magari votare contro il progetto.
Sono aperto ad ogni alternativa!
Bye
Raf

 
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.


 ai dati possono fare la grande differenza.
Grazie ancora
Ciao
Raf

 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) 

 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?
