Newsgroup: it.lavoro.informatica
Titolo: Visto che si parlava di db, progettazione, normalizzazione ecc ecc

Il progetto che mi terra' occupato a partire dall'autunno e per buona
parte dell'inverno/primavera/estate 2011, mi vedra' all'opera (non da
solo) sul sistema informatico di $medio-ente.
$medio-ente esiste da circa 40 anni e ha un sistema informatico un
tempo basato su mainframe IBM che gia' nel 2002/2003 era stato
sottoposto ad un processo di downsizing passando a dei meno costosi
AS/400. 
Nel tempo $medio-ente ha sentito la necessita' di ampliare la proposta
di servizi per i suoi associati, quindi si e' aperto un sito web, poi
un altro, poi un altro ancora. 3 siti (+ quello "istituzionale") per
tre applicazioni diverse, tenuti insieme solo dal flebile fatto di
essere poggiati su domini di terzo livello, laddove il secondo livello
e' dato  dal dominio di $medio-ente.
Non solo, ma ad un certo punto degli anni 2000 e' intervenuta la
necessita' di adeguare il proprio sistema contabile alla nuova
normativa imposta da UE e Italia, invece di adeguare il precedente
gestionale si e' scelto di acquistare un diverso gestionale (diverso
per piattaforma tecnologica, interfaccia, modalita' operative ecc.)
che cmq comunicasse con il vechcio gestionale (che non e' stato
abbandonato ma che continua ad essere usato anche se meno di prima). 
Quindi sostanziaamente questa e' la situazione che ci siamo trovati di
fronte:
- Gestionale core/legacy: DB2 come base dati, COBOL, RPG e tanticchia
di Java come linguaggi, AS/400 meglio Power system come ambiente;
- Amministrazione/contabilita': MsSQL come base dati, dotnet, c++ e vb
come linguaggi, ovviamente in ambiente Windows;
- Sito web istiruzionele: DB2 come base dati, cms jee, solaris based;
- web app 1: DB2 come base dati, jee come linguaggio con websphere
come applciatione server, windows (2000) come s.o.;
- web app 2: Oracle come db, jee come linguaggio, bea come application
server, linux red hat come s.o.;
- web app 3: DB2 come base dati, dot net (meglio le estensioni dot net
per IIS) per il frontend web (che praticamente si occupa solo del
rendering delle pagine) che dialoga con il backend tramite webservices
scritti in java.
$medio-ente ha circa 100.000 associati sparsi per tutta l'italia
(persone fisiche e giuridiche), 35 sedi in ogni regione collegate
tramite una mpls.
L'anagrafica di base conta pocomeno di 90.000 record "distinct", lo
"storico" (10 anni in linea per interrogazioni, le cose piu' vecchie
vengono di anno in anno archiviate su nastro) 20 milioni di record.
Lo storage complessivo attuale si aggira sul mezzo tera di dati (ma e'
destinato a crescere "mostruosamente" causa nuovi compiti delegati da
ministeri e nuove normative comunitarie)
Curioso notare come questo viene gestito, praticamente ad inizio anno
vi e' un record per ogni associato, mano a mano che i singoli
associati mutano il loro status e/o condizione, i programmi non vanno
mai in update del singolo campo, ma dovendo garantire la
storicizzazione inseriscono il nuovo record pari pari al precedente
con il solo campo necessario modificato. (Per una serie di ragioni che
non sto' qui a discutere, am che sono riassumibili nel classico
problema del contatore saturo, e' una delle prime cose cui dovremo
mettere mano).
Il nostro mandato? Dare una risistemata a tutto questo amba-aradan,
razionalizzando il razionalizzabile, consolidando il consolidabile,
integrando l'integrabile, risparmiando il risparmiabile...  

 integrando l'integrabile, risparmiando il risparmiabile...
Auguri!
Questi sono progetti molto interessanti, se ci sono i soldi per farli.... :)



Quoto !!
In bocca al lupo ! E non litigare con il tuo collega se tu proponi un db
transazionale vs tabella flat :-P
PaF

 integrando l'integrabile, risparmiando il risparmiabile...  
Bel progetone, compliment!

cambiare..  e ti č andata bene che non c'č neppure un angolino SAP !
ah si, m'ero scordato le Macro di Word, le fondamentali Macro di Word
(finora ne ho contate gia' 5 ed abbiamo appena incontrato 2 uffici su
14), excel fortunatamente e' usato solo come formato di output dei
dati...

mettere mano).
Non e' cosi' curioso : la storicizzazione e' un classico delle Basi di dati.
Ci sono varie strade.
Se il db e' (sara') normalizzato va messa la update-date in chiave primaria
praticamente su tutte le tabelle del db.
Se invece usi, come 99% dei casi di oggi, un db a chiave singola su tutte le
tabelle, te la giochi con una foreign-key che vai a relazionare con alcune
tabelle principali ( occhio ai cicli ) e poi tieni l'integrita' via Software.
Buon lavoro :-)
-- 

Ci sono varie strade.
Il curioso e' che oggi c'e' come chiave primaria una sorta di
unique_id auto incrementante (che in realta' e' un campo di una
tabella del db chiamata "numeratori" che e' un numerico di 8 posizioni
mica di 16 o 25 come spesso ho visto in giro) che ha quasi finito la
sua capacita' (abbiamo calcolato che agli attuali ritmi di lavoro c'ha
al massimo altri 3 anni di vita, e siccome gia sappiamo che dal 2011 i
ritmi di lavoro aumenteranno probabilmente c'hanno al massimo 16/18
mesi di lavoro), il curioso e' quello di sapere perfettamente che tra
16/18 mesi molti programmi smetteranno semplicemente di funzionare
(ovviamente no, perche' stiamo gia lavorando per superare il problema,
e no non si puo intervenire con una semplice alter table, quando non
sei sicuro della erfetta corrispondenza tra sorgente e binario in uso
per ricompilare in caso di problemi). 

 praticamente su tutte le tabelle del db.
Soluzione che odio, sporca troppo le tabelle di produzione. Preferisco
le shadow, controllate da DB se l'applicativo  cambia pochissimo, se
no dizionario data/tabella/chiave/valore e via.

equinozio ha scritto:


Gia' perche' se ti e' mai capitato quando si sale a profondita' 2 , 3 o
superiore ci si ritrova con tabelle che in chiave hanno magari 2, 3 , N 
update-date provenienti dalle chiavi delle tabelle relazionate.
La cosa curiosa a livello teorico e' che la teoria classica dice che
questa e' la strada corretta.
Inoltre da quando si usano pattern tipo hibernate ( ma anche prima ), che
sostanzialmente sono allergici alle chiavi composite, la teoria classica
tende a essere "infranta" da tutti a favore del counter-chiave su ogni
tabella, che comuqnue degrada la leggibilita' del db pure lui
ciauz Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 tabella, che comuqnue degrada la leggibilita' del db pure lui
Si ma almeno se devi cercare un record lo trovi.
Le peggiori sono quelle che usano il numero unico generato da SQL, un
identificativo tipo di 30 caratteri assolutamente causale, e secondo
me spesso lo usano per non sanno leggere il numero dell'indentity
della riga appena inserita e propagarlo.


Senza considerare che se non usano la versione che genera sempre guid 
progressivi, hanno l'indice frammentato in modo molto pesante, e siccome 9 
su 10 l'indice sulla pk lo fanno pure clustered, c'hanno proprio la tabella 
che fisicamente è tutta frammentata...
Comunque ci sono quelli che dovendo allineare dati tra db diversi usando i 
guid incrementali per essere sicuri di non avere conflitti durante le 
"riconciliazioni".

della riga appena inserita e propagarlo.
Le sequence native dici ? Sempre a favore pure io delle sequence native, anche
se non sono portabili chissenefrega e si dorme sereni che non sbagliano mai.
Il counter universale invece lo mastico tutti i giorni perche' il Portal che
uso io non so perche' lo ha da sempre e davvero li' ho sempre il dubbio che
prima o poi finisca i bit e auguri,  ....
se proprio devo dirlo la cosa peggiore e' quando si decide di generare gli id
via software con i server in balancing :-)
Li ci sono algoritmi di tutti i tipi che a leggerli viene il mal di testa,
pero' sono divertenti :-) 
Nicola
-- 

tabella, che comuqnue degrada la leggibilita' del db pure lui
tempo fa su di un altro newsgroup, mi sono trovato a confrontarmi con
un altro tecnico molto in gamba rispetto a due differenti stili di
gestione dati/programmazione, il primo (magari piu' aderente alla
teoria classica da te citata) che porta alla creazione di un unique_id
(magara autoincrementante) per ogni tabella, assicurandosi che tutte
le tabelle collegate si scambino i loro unique_id arrivando al
paradosso (secondo il classico esempio testata-ordine, righe-ordine,
evasione-ordine, ecc che l'ultima tabella dovrebbe riportare gli
unique_id di tutte le precedenti collegate) e chi come me preferisce
un sistema di c.d. chiavi naturali o parlanti (fermo restando che
l'utilizzo eccessivo di foreign key puo' a volte essere
controproducente dal punto di vista delle prestazioni.
In linea di massimo sono convinto che le opinioni tecniche sono come
le palle, ognuno ha le proprie e l'importante e' solo che funzionino,
tuttavia se ci si trova ad avere un db che deve fungere da base per
molteplici applicazioni, scritte in molteplici linguaggi in molteplici
ambienti operativi, credo che alla lungo gli unique_id rappresentino
un limite alla leggibilita' del dato, il problema con i "framework"
tipo hibernate non e' tanto che richiedano obbligatoriamente una
chiave senza che a volte (sono blasfemo) vi sia bisogno di una chiave
(ergo andrebbero usati come le medicine solo quando sia strettamente
necessario).  

"riconciliazioni".
Infatti come tutte le cose hanno pro e contro.
I counter nativi possono andare in difficolta' se ci sono piu' di un database
In quel caso l'unica e' generare via software e come dicevo prima, se i server
sono in balancing scattano una serie di nuove problematiche da settimana
enigmistaca :-)
-- 



Verissimo quello che dici, il punto di hibernate e' che lui oltre alla
mappatura e' una cache e se non ha una chiave univoca non trova il record in
memoria, o peggio ne ha piu' di uno sulla stessa chiave e li "brucia" tutti
letteralmente eccetto uno a caso come non esistessero gli altri, quindi la
cosa migliore ( se non obbligatoria ) e' avere una chiave secca contatore.
Concordo che non esiste la strada universale, se ne prende una e la si porta
avanti "con le proprie palle" :-)
N
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 integrando l'integrabile, risparmiando il risparmiabile...  
Ho la vaga impressione che la mia pensione sia nelle tue mani... ;^)
bye!

 della riga appena inserita e propagarlo.
Beh, dei motivi a volte ci sono per scegliere una chiave del genere -
il fatto che le chiavi siano numeri sempre crescenti può dare adito a
problemini nella gestione della sicurezza e della concorrenza.
Ma alla fin fine anch'io sono della squadra che opta per chiavi
semanticamente significative ovunque possibile, anche se non sono
talebano al riguardo.
bye!

 problemini nella gestione della sicurezza e della concorrenza.
Si, ci possono essere motivi, ma devono controbilanciare
l'impossibilità di ricordare e scrivere a mano una chiave.. quando poi
ti ritrovi a scriviere
select where id = 'ASDWERWERASD-ASDEWR342RFCSD-WEFWEFWEEF-CSDCSD34F434-
VDSVSDCSDWE224T3'
ci ripensi.. se non altro per gli accidenti che ti riverseranno tutti
quelli che verranno dopo di te ;-)
PS: alla sicurezza non ci avevo pensato, ma comunque non puoi esimerti
da fare il chek sicurezza ad ogni lettura.. quindi.. tanto vale.

 enigmistaca :-)
Infatti, ma in quel caso il limite della fantasia è il cielo :  si può
partizionare i dati per talmente tante cose, scegliere talmente tante
strade e possono essere così nefasti gli effetti di una scelta
sbagliata che è perfino divertente.

 quelli che verranno dopo di te ;-)
-------------
se scrivi nel codice una selcet con dentro hardwired delle chiavi te
li meriti anche gli accidenti ;^)
bye!

 le palle, ognuno ha le proprie e l'importante e' solo che funzionino,
Si, nei limiti del nomale però....

 li meriti anche gli accidenti ;^)
Che codice ? Perchè un sql pad non lo usi mai ?
E poi una mano a chi mette a posto i dati mano non la vogliamo dare ?

 Ho la vaga impressione che la mia pensione sia nelle tue mani... ;^)
Sarebbe simpatico un "piccolo" errore in una query di update, e *zac* vai
in pensione a 50 anni con 5000 euro al mese :-P
Suarez se vuoi ti offro una birra :-)
PaF
PS.
Si scherza !

 Suarez se vuoi ti offro una birra :-)
guarda, se mai arrivo alla pensione e riesco a riscuoterla, gli pago
una birra a settimana io finchè campo ;^)
bye!

 E poi una mano a chi mette a posto i dati mano non la vogliamo dare ?
quelle chiavi lì sono pensate proprio per non essere mai inserite a
mano, ma gestite solo dal sistema. Altrimenti sempre e solo chiavi
parlanti o ti chiami de Sade...
bye!

 parlanti o ti chiami de Sade...
seee.. lo devo ancora vedere un sistema gestionale dove nessuno fa
query e corregge qualche dato a mano

 query e corregge qualche dato a mano
Io mica ho detto il contrario, infatti. Non è necessario esporre la
chiave all'utente per consentirgli di modificare i dati...
bye!

 sbagliata che � perfino divertente.
Gratz a tutti, vedete che se vogliamo e soprattutto se lasciamo fuori la
politica siamo
pure qua su ili capaci di fare una bella discussione da nerd ? :-))))
Buon fine settimana a tutti e auguri coi prossimi db , una delle parti
dell'indormatica piu' concreta e affascinante allo stesso tempo: nel mio
sogno, e non solo mio , non cosi' irrealizzabile, si arrivera' a un db unico
universale, sepolto nel deserto, o sotto un ghiacciaio, con tutti i dati del
pianeta, ci vuole qualche centinaia di anni o forse meno visto che la teoria
dei database e' solo degli anni '70 o poco prima
Buon fine settimana a tutti e ancora buon lavoro a Suarez :-)
Nicola


 pianeta,
sogno? un INCUBO! :^)
bye!


Wow, pensa ai  dba allegati a questo db, bel posto per lavorare! :-D

 unique_id di tutte le precedenti collegate)
Non oso immaginare cosa sarebbe uscito fuori ti fossi confrontato con un 
tecnico che invece era una pippa :-)

 wrote in message 
news:i0kj8f$hm4$1...@tdi.cu.mi.it...
guid incrementali � una cosa che mi mancava.....
 


Esistono davvero, mica me lo sono inventato io:
http://msdn.microsoft.com/en-us/library/ms189786.aspx

 wrote in message 
news:i0mmfl$196$1...@tdi.cu.mi.it...

Una pippa mentale di quelli di SQLServer....
 

 Una pippa mentale di quelli di SQLServer....
Mi sono toccati in un DB. E' un tipo di campo che aggiunge SQL per la
replica (e fino lì c'avrei da lamentarmi ma visto che fa tutto lui sto
zitto ), comunque lo puoi anche usare come chiave primaria. Poi ogni
record sembra la chiave di attivazione di windows efra colleghi le
conversazioni diventano :
- che riga è quella dell'errore ?
. scrivi id = a come alimortacci sua, l come limortaccisua, t come
teelimortaccisua e così via per 20 o più caratteri

 necessario).
Manca un ma e frase a seguire. E comunque le tabelle senza chiave sono 
una porcheria di cui non vedo proprio l'utilità