Newsgroup: it.comp.os.dibattiti
Titolo: Database

Oggi ho comprato 
inter.net
 di novembre con su la redhat 5.2. Bene. Già
installato e funzionante.
Sulla rivista c'è un'articolo che parla delle suite office per Linux. Bene
(o male...)
Tralasciando i vari WP e Spread-Sheet più o meno pregevoli quando si và sui
database
non se ne trova uno per utenti. Mi spiego meglio. Nell'articolo quando si
parla di DB si
fà rifermento a PostgreSQL. Ok.
PostgreSQL è un DB. Certo ma un DB server. Non è una cosa paragonabile ad un
Access (che in realtà non è un database ma piuttosto un front-end
sofisticato e programmabile) oppure ad un Approach di Lotus (pure lui più
front-end che DB).
Di Word processor e Spread-Sheet è pieno il mondo (se volete vi mando i miei
WP ed i miei
Spread-Sheet Excel compatibili) e pure un bimbo sa scriverne usando delle
librerie sia free che shareware che commerciali. Un front-end per DB è gia
qualcosa di impossibile per le brillanti menti del free-software? Non credo
proprio.
Aspetto vostre segnalazioni.
Saluti.

 proprio.
Perche` fare a colpi di click cio` che si fa in un attimo con due colpi di SQL?
Forse che la sola presenza di un'interfaccia grafica ti impedisce di fare un
database mal progettato, o meglio, ti aiuta a farne uno progettato bene? 
Se fai un paragone con il campo del DTP, vedi cosa e` successo: dai in mano un
software di impaginazione decente a chi impaginatore non e`, e te ne esce quasi
sempre solo roba illeggibile con 3mila font arzigogolati che piu` arzigogolati
non si puo` (che va bene per la festa della parrocchia, ma non per altro).
Allo stesso modo dai in mano un ambiente che ti da la falsa illusione che tutto
sia semplice e immediato a uno che ha scoperto le basi di dati due ore prima, e
quello che ne viene fuori e` cacca. Dallo in mano ad una persona piu` esperta e
ti ritrovi dopo dieci minuti che si chiede "come cavolo faccio a fargli fare
quello che voglio io e non quello che vuole lui? Uffaaaaaa!". E qui unicamente
in quanto buona parte delle interfaccie "amichevoli" sono amichevoli solo per
chi le ha progettate, ma fungono da buon specchietto per le allodole.
A far database a colpi di click (leggi: senza preventiva progettazione) ne
vengono fuori solo database nati male. Se uno deve progettare database a colpi
di click, forse deve considerare il fatto che non e` la persona piu` adatta a
farlo.
E, infine, se i dati sono pochi, uno spreadsheet basta e avanza, no (cosi`
facciamo contenti anche quelli che si fanno l'archivio dei CD).

 proprio.
Se fai il paragone con access, la domanda è malposta: in realtà dovresti
chiedere se è possibile un personal database.
In un sistema come un dbms il front-end per l'utente è possibile eccome... è
l'applicativo client.
--
Marco
- Dove vuoi essere mandato oggi®?

non ho mai provato).
Puo' essere usato un piccoli ambienti multi utente, diciamo 5-6 accessi
contemporanei.
Il problema grosso e' il look di pagina, ma in Access 2000 verra' introdotto
il look a livello di record.
Ciao
Francesco

 il look a livello di record.
Già qualcosa, per un multiutente.


l'applicativo client.
Marco, non ci hai capito niente......qui stiamo parlando di front-end di
interrogazione ed analisi.
Non di client di accesso al DB....quello stà sotto.
Saluti .

Già qualcosa, per un multiutente.
SQLServer 7 è sufficiente? (Perche il nuovo db engine di Access è SQLserver
7)
Saluti.

 interrogazione ed analisi.
Mah, sai... con oracle sono abituato a SQL Plus per l'interrogazione e analisi.
A me non sembra che con Access si possa fare tanto di più, a parte ovviamente la
grafica bellina e il drag&drop.


grafica bellina e il drag&drop.
Marco, ma tu cosa intendi per analisi? Guarda che il data mining non č fare
una "select * from miatabella".
Saluti.

 una "select * from miatabella".
E infatti io non intendevo proprio fare una select...

Mi spiegeresti come? (sto parlando sul serio senza polemica, sono interessato)
Boh. io l'ho collegato ad un AS400/500, e per farmi un'analisi ODBC
sugli ordini ci ha messo 6,5 ore...
Obelix

> il look a livello di record.
Look???? non credo di essere interessato a come appre la pagina....
Obelix che ha il Record-locking dall'88...

7)
Boh. dipende. Trigger?? Double-level commit?? viste logiche?? viste
logiche parametrizzabili?? Union??  vie d'accesso condivise?? 
Obelix

...

Peccato che per tirar fuori i dati quella devi usare.
Ciao.

...

Ci stanno tutte e pure qualcosa di più.
Ciao.

...

Obelix, ci hai un cesso di macchina. Fatti una macchina seria...se proprio
sei al verde fatti almeno  un 170 di quelli con le contropalle e 400 di
prestazioni C/S...
Ciao.

farlo.
Chissa perchè i programmi di analisi e progettazione di database e processi
sono grafici..
Ciao.

 sono grafici..
Perche` manco ci si vuol scomodare piu` a tirare due righe a matita su un foglio
di carta  o col pennarello su una lavagna, o a mandare un paio di mail ai
colleghi... Capisco che un modello grafico con simbologia dall'interpretazione
non ambigua e` comodo, ma e` utile piu` per ricordarti/far ricordare cio che in
precedenza ti e` stato spiegato/hai spiegato che per progettare la cosa.
Citami l'esempio di un'azienda ove sviluppatori e progettisti siano FELICI (o
quantomeno dichiarino che sono di gran lunga FACILITATI) di poter PROGETTARE
tramite tools grafici (a priori, ovviamente, non a posteriori) qualcosa CON
L'ESCLUSIVO AUSILIO di programmi di progettazione grafica.
Sara`, ma IMHHHO (con 3 H, a questo punto) o il fesso sono io che vado ancora in
giro con il mio foglio ordinatamente scribacchiato a mano a sentire i
responsabili di aree collaterali a quella in cui opero, o i fessi sono chi
questi tool se li compra e li vede marcire giorno dopo giorno sul file server di
turno.
A POSTERIORI sono perfettamente concorde. Un buono schema e` senz'altro una cosa
utile a chi prendera` in mano (se mai verra` quel giorno) il mio software.
Ovviamente, NON sara` l'UNICA documentazione allegata.

 grafica delle cose non è che sia male. Hai presente cose come Erwin?
Io ho presente PowerBuilder. Ha la possibilità di definire le query
graficamente. Questa caratteristica aiuta allorchè velocizza la ricerca delle
tabelle e delle colonne.
Le query complesse però vanno costruite a mano (almeno con pb) senza togliere
niente al fatto che questa feature aiuta molto nella "generazione" iniziale
della query.


prestazioni C/S...
il che, essendo il mio 170 a 220, ridurrebbe i tempi del 50%, a circa
3.2 ore (macchina dedicata. of course..) 
Il problema e' che ODBC fa schifo assai, e che per db sopra una
dimensione appena umana Access, semplicemente, si siede...
Obelix

Ci stanno tutte e pure qualcosa di piů.
Mah. Da un software che, ancora quest'anno non aveva il record locking
mipare strano...
Ah, gia' che stupido: Li ha. Hmm. E quando funzioneranno??
Obelix

3.2 ore (macchina dedicata. of course..)
Dato che le query SQL vengono passate all'AS/400 cosě come tu le scrivi
(cosě come dice la documentazione del driver ODBC di C/A400)
ne desumo che il probema sia dell'AS/400.
Se poi fai delle elaborazioni sulla trasformazione dei campi con funzioni
non
supportate dall'SQL del DB2/400 (es. sulle stringhe o sulle conversioni di
tipo)
la cosa č fisiologica, ossia avresti quei  tempi di risposta su tutti i
sistemi che usano
un interprete.
Saluti.

ne desumo che il probema sia dell'AS/400.
Hai detto la tua coglionata giornaliera, si??? sei contento, vero??
Ovviamente, non ti passa neppure per l'anticamera del cervello di
informarti su cose *secondarie* realtive al tempo di trasferimento
quali il numero dei record reperiti, il numero dei campi ed altro.
Ne' ovviamente, il tuo pilkkolo cervellino ha mai preso in
considerazione che quegli stessi SQL Statement uno li possa far girare
direttamente a mano (STRSQL immagino sia un comando sconosciuto, per
te...) per avere i tempi del SOLO comando di estrazione e notare
strane discordanze. 
Ovviamente, preferendo io le strade piu' contorte a quelle lineari
insegnate dai commerciali MS ("e' lento? comperi in Hardware piu'
veloce" ma imparate a scrivere il software, piuttosto...) ho risolto
elegantemente buttando nel cesso quella ciofeca di ODBC e usando un
banale, grezzo e velocissimo CA file transfert.
Btw, visto che, incredibile dictu, sai leggere e leggi la
documentazione allegata al driver ODBC spero non ti sia sfuggito quel
paragrafo che dice, piu' o meno, "non e' colpa nostra se quei
deficenti della MS hanno fatto delle specifiche di creazione idiote
che fanno si che ODBC sia un protocollo molto lento".
Obelix

che fanno si che ODBC sia un protocollo molto lento".
Chissà poi prchè questi problemi che li ha solo IBM sull'AS/400?
Ah si mi viene in mente il favoloso Ole-DB provider del CA/400...due anni e
non riescono ancora
a farlo funzionare..Mi sorge un dubbio.
Dato che TUTTI gli altri produttori di Database relazionali riescono a
creare dei driver ODBC
ed OLE-DB che vanno come le API native dei loro DB, non sarà mica che quelli
di IBM hanno
un problema intrinseco nel loro versante. Ossia, Il DB ed il sottosistema di
rete dell'AS/400.
E se così non fosse, mi spieghi l'enfasi posta da IBM sul Netserver del
OS/400 4.3?
ODBC  è lento quando il DB non è un DB nato Relazionale....(e DB2/400 ha
ancora qualche problema sotto questo aspetto. Chissa perchè poi IBM chiama
DB2 qualsiasi DB rilasciato con
i suoi S/O....DB2 a stretta osservanza si trova solo sugli ES/9000, su AIX,
su NT e OS/2, quello
dell'AS/400 sino alla versione 3.7 manco era un RDBMS)
Saluti.

quello dell'AS/400 sino alla versione 3.7 manco era un RDBMS)
Poi mi chiedi 'quand'e' che dico stronzate io??' Adesso, per
esempio....
Obelix

questa me la devo segnare...
Hai presente le funzioni di dizionario? Hai presenti le funzioni di schema,
ossia
quelle che dicono come è composta la primary key di  una tabella? Quelle che
dicono
da quali campi è composto un indice?
Si ma il fatto rimane quello...ossia che quello dell'AS/400 sino a 3.7 (fino
a 4.1 dico io) non
era un RDBMS. Cecchè tu ne possa dire. Mi spiace per te.
Saluti.

... non gli badare. E' inutile che vi incasinate con sta discussione
infinta (che ho seguito fin qui); č tutta colpa di una pozione di
Panoramix.
Prima o poi svanirŕ l'effetto e potrŕ tornare ad essere come tutti noi:)
-- 
Ciao ....
       Massimiliano ADAMO
    E-mail: 
maxa...@usa.net


iQA/AwUBNmzBu4R/hNGN/z6CEQJyfwCeIoyz9RL5FNShFPK++ngFsFptLewAoONT
EPVy85J1qculpayhFmbFQkY4
=sN/8
-----END PGP SIGNATURE-----


iQA/AwUBNmzCeYR/hNGN/z6CEQLSdQCfUnOzl1wYRPwLd2BqZfy2+A2DzqgAoNVz
CggCjhaMHaZk7WREMvUfBRQu
=2Tcx
-----END PGP SIGNATURE-----

preoccuparsi di DB2
Ecchene un'altro che parla parla ma non conosce l'argomento del parlare.
I Driver ODBC (i driver, non il driver manager) vengono scritti dal
produttore del database.
Quello per l'AS/400 allegato con il CA/400 è scritto dall'IBM. Quindi chi
meglio di loro conosce
DB2?
Saluti.

a 4.1 dico io) non era un RDBMS.
Lo guardo, e cerco di capire cosa dice.. non ci riesco. Facciamo una
prova: spiega perche' eh??
Obelix btw, quelle funzioni c'erano nella 2.3.0 perche' e' la prima in
cui ho iniziato a programmare. probabilmente, c'erano anche prima
(dovrei chiedere...)

meglio di loro conosce DB2?
Vero: ma le limitazioni di ODBC sono parecchie..
Obelix

2.3.0
Non significa niente. Anche il formato file del DBII (quello per PC di
Ashton-Tate) aveva la definizione
dei campi inglobata e la definizione degli indici inglobata nell'indice. Non
dirmi che DBII era
relazionale.
Avere una sovrastuttura di interrogazione SQL non significa che un DB è un
RDBMS
(per inciso non mi risulata esistere nessun RDBMS conforme al dettato di
Codd).
Tuttavia possedere delle tabelle contenti la definizione delle tabelle,
delle colonne, degli  indici,
delle viste (le View, non le viste logiche dell'AS/400), i trigger, i
constraint e compagnia cantando
consente di implementare cose come gli ottimizzatori ed aiuta alquanto
quando si tratta di restituire le informazione sulla natura dei dati (delle
colonne insomma) in termini di dominio.
Altre cosine sono relative all'integrità referenziale (dichiarativa). Posso
sbagliare ma tutte queste
cosine non esistevano prima del 3.1/3.6 (o 3.2/3.7).
Saluti.

Posso sbagliare 
Si, direi decisamente di si (btw, sei gia' tornato indiero da 3.7.0 a
3.1.0.... fra unpo' ti trovero' alla 1.3.0)
Obelix

Bel giovane, stavamo parlando di 'Access come strumento di anali ed
                                                            ^^^^^
Tipo esempio di lapsus freudiano?!?!?! ;-)))))							    
Ciao.
-- 
Warning!
Don't send any mail for me at my from: or replayto: addresses ;
I just kill the mail over there without reading!

3.1.0.... fra unpo' ti trovero' alla 1.3.0)
E invece mi pare proprio di  no..
Saluti.

3.1.0.... fra unpo' ti trovero' alla 1.3.0)
Ho ricontrollato frà i package dei miei AS. Il primo vero DB qualificabile
come RDBMS su AS/400 è apparso con OS/400 3.1 e OS/400 3.6, anno di grazia
95/96 se non erro
(non ho controllato le date sulle lettere di accompagnamento...)
Anche se ad onor del vero queste release (3.1/3.6)sono durate praticamente
da Natale a S. Stefano.
Ciao Ciao.

E invece mi pare proprio di  no..
Se hai appena citato un Driver ODBC che funziona con 2.3.0...
Obelix

 produttore del database.
Non sempre. MS fornisce driver per Oracle a richiesta. E anche per
DB2, temo.

...

Quarda che ODBC crea una struttura SQL autonoma se il DB non possiede un
motore SQL proprio. Guarda caso parlavo proprio di in driver Intersolv, che
frà l'altro, procuce(va) dei driver ODBC anche per file di testo. L'engine
SQL di Intersolv sta(va) nelle DLL QEUTILxx.DLL e QEBASxx.DLL. Quello in
questione leggeva la definizione
dei file AS/400 e da quella creava (simulava) le funzioni di dizionario che
OS/400 non aveva (sino a 3.1).
Saluti.

...

Quelli per Oracle si. Per il DB2 distribuisce (su SNA server) un driver
(demo...) non suo. Na fetecchia....
Di norma preferisco usare quelli del produttore del DB. (anche se ad onor
del vero i driver di Intersolv
sono molte volte meglio..)
Saluti