[db] Oracle XE: una bella risposta a mySQL? [Archivio]

Nightingale

01-03-2006, 11:03

Mi farebbe piacere parlare e sentire il parere di altre persone riguardo l'uscita del database Oracle XE (http://www.google.com/url?sa=U&start=1&q=http://www.oracle.com/technology/products/database/xe/&e=9797).
Io ci lavoro da quattro anni, sulle versioni 8.1.7 e 9i. Adesso finalemnte è possibile sfruttarne l'intera versatilità anche in versione gratuita (con qualche limitazione, ma non funzionale a parte quello delle istanze).

Non gode della leggerezza di mySQL (i suoi 300 mb di ram su win alla fine se li succhia), ma è davvero un bell'oggetto a mio parere. Package, procedure, function e trigger. Senza considerare i vari objects su DB, le viste, il commit ed il rollback. Inoltre ha in "bundle" anche l'HTML DB, per creare "facilmente" applicazioni web... Oppure l'integrazione di Oracle Zend PHP.

pippo985

01-03-2006, 11:27

Utilizzo Oracle da oltre 5 anni e ne ho apprezzato tutte le funzionalità anche in maniera spinta.
Avevo letto della versione gratuita, ma non ho avuto tempo di provarla.

Cmq se non ci sono delle "limitazioni" ed è liberamente distribuibile, la vedo un po dura per mysql. Io sto utilizzando la versione 5 con tutte le nuove features tipo procedure, funzione, etc, ma Oracle è un "attimino" avanti :cool:

Fenomeno85

01-03-2006, 12:04

pippo985

01-03-2006, 12:08

solo un attimino?! :asd: ... viene utilizzato nel mondo super professionale :D se non erro i db della Alitalia lavorano sotto oracle ;)

~§~ Sempre E Solo Lei ~§~

Era in senso ironico :O :O :O
Sapessi quante società grandi lo usano ;)
Quando arrivi ad un certo livello di grandezza la scelta è obbligata :cool: :cool:, anche se costa....e come se costa :cry: :cry: :cry:

Fenomeno85

01-03-2006, 12:10

Era in senso ironico :O :O :O
Sapessi quante società grandi lo usano ;)
Quando arrivi ad un certo livello di grandezza la scelta è obbligata :cool: :cool:

si appunto alla fine esiste solo SQL server e Oracle :D

~§~ Sempre E Solo Lei ~§~

pippo985

01-03-2006, 12:12

si appunto alla fine esiste solo SQL server e Oracle :D

~§~ Sempre E Solo Lei ~§~

Ahhhhhhhhhhhh non nominare quel nome :D :D :D

Fenomeno85

01-03-2006, 12:14

Ahhhhhhhhhhhh non nominare quel nome :D :D :D

Bhe dai anche lui è utilizzato in ambiente professionale :D ... avevo sentito però non so se erano cavolate o meno che se si ha un blocco di Oracle (su aziende di un certo calibro) escono direttamente i tecnici è vero?

~§~ Sempre E Solo Lei ~§~

pippo985

01-03-2006, 12:17

Bhe dai anche lui è utilizzato in ambiente professionale :D ... avevo sentito però non so se erano cavolate o meno che se si ha un blocco di Oracle (su aziende di un certo calibro) escono direttamente i tecnici è vero?

~§~ Sempre E Solo Lei ~§~

Nel senso che arriva direttamente l'assistenza Oracle? Non so, qui abbiamo un buon DBA e blocchi non si sono mai verificati.

Fenomeno85

01-03-2006, 12:22

Nel senso che arriva direttamente l'assistenza Oracle? Non so, qui abbiamo un buon DBA e blocchi non si sono mai verificati.

si esatto .. se è un problema di oracle che muore allora escono subito

~§~ Sempre E Solo Lei ~§~

mailand

01-03-2006, 12:43

si esatto .. se è un problema di oracle che muore allora escono subito

~§~ Sempre E Solo Lei ~§~
come sempre, basta pagare, e ce l'hanno tutti i grandi produttori sia di hardware che di software, da ibm a sap, da oracle ad hp ;)
in base ai contratti di assistenza, hai diversi livelli/priorità per ridurre al minimo i blocchi su applicazioni critiche che possono prevedere anche l'uscita entro 2 ore di un sistemista oracle. inoltre, per problemi applicativi, esistono i metalink, ovvero la knowledge base di oracle: ci sono forum, bug e relative patch, relase e patchset e relative istruzioni di aggiornamento. inoltre, con errori non bloccanti a livello sistemistico ma applicativo, puoi aprire una "TAR" (un caso), cui viene assegnato un numero, e oracle elabora la soluzione lavorando 24 ore su 24 tramite i centri di assistenza sparsi nel mondo. per supplementi di indagine riguardo ai tar, oracle ha sviluppato un software, l'RDA (remote diagnostic agent) che permette ai tecnici di estrapolare tutte le informazioni relative alla macchina e all'istanza per replicare quanto più fedelmente il problema...

ritornando in topic: qualcosa c'era già prima (oracle 9i lite) ma non ha mai entusiasmato... proverò a vedere anche questa xe, magari su un personal use potrebbe essere una valida alternativa a sqlserver o mysql...

Nightingale

01-03-2006, 16:11

Questa versione XE è libera da distribuire, scaricare e sviluppare. Databse ed HTML DB, oltre allo Zend PHP.
Le uniche limitazioni che offre sono 4Gb di dati, 1 Gb di utilizzo memoria da parte del processo database, e la creazione di una sola istanza.

Io lavoro su Oracle per conto di Coop. Abbiamo anche noi un buon dba. Se qualche volta il processo si è interrotto, per ora, è solo stato per colpa dei dischi.
In effetti mySQL 5 ha fatto un gran balzo, con trigger e procedures. Ma, per esempio, adesso supporta commit e rollback senza il modulo InnoDB (che non è più free)?

pinok

01-03-2006, 16:37

solo un attimino?! :asd: ... viene utilizzato nel mondo super professionale :D se non erro i db della Alitalia lavorano sotto oracle ;)

~§~ Sempre E Solo Lei ~§~
Se paghi, anche MySQL offre assistenza.
I clienti di MySQL li hai visti ;) ?? Non sarà Oracle, ci mancherebbe, ma non stiamo parlando di un db per i poveracci...
E vuoi mettere la NASA con MySQL rispetto all'Alitalia con Oracle :sofico: ??

http://www.mysql.com/customers/

Alcuni nomi tratti dalla lista sopra linkata:

* AIRBUS/EADS
* EUROCOPTER
* French Ministry of Defense
* Los Alamos National Laboratory

* Google
* Lycos
* Yahoo

* Una sezione del CERN
* Una sezione del MIT

* Deutsche Post
# NASA
# NASA Jet Propulsion Lab (JPL)
# State of Illinois
# State of Michigan
# State of Minnesota
# State of New York

* UNICEF
* Epson
* Toyota
* Yamaha

* BBC
* Bloomberg
* CNET
* Slashdot
* Wikipedia

ecc. ecc.

mailand

01-03-2006, 16:53

Fenomeno85

01-03-2006, 16:59

mailand

01-03-2006, 17:19

apperò

io son rimasto così quando ho letto questo :sbavvv:

http://www.oracle.com/global/it/customers/profiles/profile_67.html

180 milioni di record è qualcosa di allucinante in un giorno ... non oso immaginare i server come sono strutturati :D

va be questi sono solo quelli italiani http://www.oracle.com/global/it/customers/cust_list_atoz.html#A

~§~ Sempre E Solo Lei ~§~

in effetti la quantità di record fa impressione e sicuramente avranno una notevole struttura (RAC, full mirroring, disaster recovery immediato e chi più ne ha più ne metta), ma secondo me sono database piuttosto semplici e a sviluppo verticale (tabelle con poche colonne)...
mi fanno più paura aziende dove magari hai un milione di record alla settimana ma con 70-80 colonne

Fenomeno85

01-03-2006, 17:21

in effetti la quantità di record fa impressione e sicuramente avranno una notevole struttura (RAC, full mirroring, disaster recovery immediato e chi più ne ha più ne metta), ma secondo me sono database piuttosto semplici e a sviluppo verticale (tabelle con poche colonne)...
mi fanno più paura aziende dove magari hai un milione di record alla settimana ma con 70-80 colonne

si bhe anche le tabelle della lottomatica non devono scherzare, informazioni utente, che diavolo ha puntato ect.. comunque si db immensi fanno paura .. chissà se un giorno riuscirò a crearne uno o semplicemente progettarlo :D

~§~ Sempre E Solo Lei ~§~

Nightingale

01-03-2006, 17:30

Beh sì, fanno paura... Ed a lavorarci sopra non sono né poche persone, né pochi server. Voi pensate anche solo alla gestione deu supermercati, per la sola barriera casse. Ogni qualvota sentite un bip, dalle casse, viene scritta una riga; questo per tutte le casse (per gli iper, non è poco). E tutti i punti di vendita che poi fanno riferimento ad una database centrale. Pensate un po' come stanno le testine sotto le festività natalizie. :p

mailand

01-03-2006, 17:45

pinok

01-03-2006, 17:45

non mi sembra che siano da meno i clienti di oracle...
per il database: http://www.oracle.com/customers/products/database.html
tra cui Amazon.com, Colgate-Palmolive, Lufthansa, CELERA Genomics, Cisco Systems, NASDAQ non mi sembra che siano clienti da niente ;)

Non dicevo questo, ma solo che MySQL non è una cammellata buona per tricche e ballacche ;)

oltretutto ritengo ragionevole pensare che il DB del NASDAQ o del CRM di Colgate-Palmolive siano più voluminosi di archivi di NASA... ;)
Forse ti sfugge chi è la NASA ;) e i dati che raccolgono...
Non metto in dubbio che i dati del NASDAQ siano immensi, ma pensa anche alla NASA o a google (in questo caso pensa a indicizzare quasi tutto quello che gira sul web e a offrire interrogazioni a tutto il mondo!)

Fenomeno85

01-03-2006, 17:49

Non dicevo questo, ma solo che MySQL non è una cammellata buona per tricche e ballacche ;)

Forse ti sfugge chi è la NASA ;) e i dati che raccolgono...
Non metto in dubbio che i dati del NASDAQ siano immensi, ma pensa anche alla NASA o a google (in questo caso pensa a indicizzare quasi tutto quello che gira sul web e a offrire interrogazioni a tutto il mondo!)

per la frase tricche ballacche sarai bannato a vita :O

poi per la NASA bisogna capire per quali scopi viene utilizzato il db. L'indicizzazione è il meno la maggior parte sono interrogazioni :D

~§~ Sempre E Solo Lei ~§~q

mailand

01-03-2006, 17:53

Non dicevo questo, ma solo che MySQL non è una cammellata buona per tricche e ballacche ;)
non volevo assolutamente intendere questo, anzi, ritengo mysql un ottimo prodotto ;)

Forse ti sfugge chi è la NASA ;) e i dati che raccolgono...
Non metto in dubbio che i dati del NASDAQ siano immensi, ma pensa anche alla NASA o a google (in questo caso pensa a indicizzare quasi tutto quello che gira sul web e a offrire interrogazioni a tutto il mondo!)
non mi sfugge chi è la nasa, anzi! :) solo non ritengo (voci mi hanno detto) che i database della nasa siano più complessi di quelli di altre società... altissima tecnologia aerospaziale non fa 1 a 1 con database altamente complessi... grossi probabilmente a livello di tablespace per via di LOB o BLOB di immagini, ma non così strutturalmente complessi ;)
poi non so, magari nell'area51 sono già a mysql8 :D

se devo essere sincero sono più attonito davanti all'ottimizzazione degli indici per google, quello sì deve essere un gran lavoro :eek:

mailand

01-03-2006, 17:54

L'indicizzazione è il meno la maggior parte sono interrogazioni :D
~§~ Sempre E Solo Lei ~§~q
un'indicizzazione pessima causa pessime performances ;)

Fenomeno85

01-03-2006, 17:58

un'indicizzazione pessima causa pessime performances ;)

si daccordo con te non non metto in dubbio questo ... però se fai caso anche l'aggiornamento non è quatidiano di tutti i siti ;)
Non so quanti record nuovi al giorno vengono aggiunti o aggiornati ma penso che siano minori del milione :D

~§~ Sempre E Solo Lei ~§~

mailand

01-03-2006, 18:01

si daccordo con te non non metto in dubbio questo ... però se fai caso anche l'aggiornamento non è quatidiano di tutti i siti ;)
Non so quanti record nuovi al giorno vengono aggiunti o aggiornati ma penso che siano minori del milione :D

~§~ Sempre E Solo Lei ~§~
mi sa che sono MOLTI di più ;)

Fenomeno85

01-03-2006, 18:03

mi sa che sono MOLTI di più ;)

bisognerebbe trovare un pò di informazioni a riguardo :D

~§~ Sempre E Solo Lei ~§~

Fenomeno85

01-03-2006, 18:05

comunque vorrei farvi notare una cosa:

Dell usa sia Mysql che oracle .. quindi qui dobbiamo capire gli scopi dei due dbms :D

anzi qui c'è qualcosa che non quadra :wtf:

cisco dice che usa oracle .. eppure risulta anche sotto mysql uno dei due mente ... chi?! :D

~§~ Sempre E Solo Lei ~§~

mailand

01-03-2006, 18:10

comunque vorrei farvi notare una cosa:

Dell usa sia Mysql che oracle .. quindi qui dobbiamo capire gli scopi dei due dbms :D

~§~ Sempre E Solo Lei ~§~
non indago, ne ho già abbastanza di mio di grane :D

Fenomeno85

01-03-2006, 18:15

avete visto quanto spende solo mastercard?

COSTS
Oracle Licenses2
$150,000
Annual Maintenance
$140,000
Consulting Costs
$150,000
Internal Labor3
$158,393
Total 5 Year Investment
$598,393
BENEFITS
Headcount Savings
$1,016,000
Other Quantifiable Savings4
$2,400,000
Total Benefits
$3,416,000
TOTAL 5 YEAR NET BENEFITS
$2,817,607

penso che sia più difficile gestire un mercato NASDAQ o i miliardi di transazioni giornalieri di mastercard o altre compagnie che un motore di ricerca o no?

~§~ Sempre E Solo Lei ~§~

shinya

01-03-2006, 19:10

Per stare nel nostro, anche Coop Italia usa oracle :)
Non conosco alla perfezione mysql, ma da quanto ho letto in giro solo con la nuova versione (la 5) ha portato cose fondamentali come stored procedure, trigger e view, che oracle ha già da anni.
In particolare, le stored procedure sono un meccanismo potentissimo per eseguire operazioni sul database ed era una grossa mancanza nelle versioni precedenti di mysql (tra l'altro, non ho avuto la possibilità di confrontare mysql e oracle sotto questo punto di vista, uso solo PL/SQL per lavoro).
E poi anche i trigger, non credo che mysql supporti tutti i tipi di oracle.

andbin

01-03-2006, 20:59

Scusate se mi intrometto. Ho visto che Oracle XE può essere usato anche con Java. Con la installazione di Oracle XE viene fornito anche un qualche pacchetto jar con i driver JDBC??

Nightmare

01-03-2006, 21:47

... se non erro i db della Alitalia lavorano sotto oracle ;)

de agostini, fastweb, sky, alitalia, enav...

mentre molti db della telecom in cui ho lavorato sono in access :mbe:
ecco xke non vanno i gestori telefonici :read:

Emyl

01-03-2006, 22:18

Molto piacevole da leggere questo thread, una volta tanto non si vedono i soliti troll che puntualmente saltano fuori quando si nominano le parole "Windows" o "Oracle".

Premetto che uso sia Oracle, Sql Server e MySQL per lavoro, e che tecnicamente preferisco Oracle. Penso sia un'opinione abbastanza comune tra le persone che conoscono bene Oracle. Non e' un caso.

Non e' un caso neanche che i costi di licenza siano elevatissimi. D'altra parte se vuoi un prodotto performante, scalabile, certificato e un'assistenza diretta nessuno puo' darti tutto questo per niente. E purtroppo non e' tutto qui: se vuoi hardware certificato devi aggiungere altri costi, e anche in termini di risorse umane non e', senza false modestie, gestibile dal primo smanettone preso per strada. Niente di fantascientifico, solo che occorre studiare e formarsi a dovere per diventari buoni DBA.

Oracle XE e' nato sulla scia delle omologhe versioni gratuite di Sql Server e DB2, allo scopo di acquistare utilizzatori negli ambiti medio-piccoli, esempio tipico l'applicazione web. Non a caso la quasi contemporanea uscita del Php ottimizzato per Oracle, sempre gratuito. Il tutto senza sacrificare nessuna delle funzionalita' basilari del DBMS.

Ho visto che si parlava di grandi clienti legati ai vari produttori di db. Al di la' del prestigio, MySQL per come e' strutturato puo gestire basi di dati grandi, ma non enormi. Quelle secondo me se le dividono DB2 e Oracle. Qualcuno mi aveva detto che France Telecom gestiva, con Oracle, un data warehouse di 35 Terabyte :eek:

In Italia, o meglio nella mia zona (Firenze e dintorni), abbiamo General Electric, Eli Lilly, Menarini, Coop (non lavoro per nessuna di queste aziende :) )

pinok

02-03-2006, 01:42

Penso che, nonostante mysql sia un ottimo DB che può competere con Oracle, occorra anche tenere conto dei target di utenza e della complessità d'uso.
Oracle è più orientato a grandi realtà, ma difficilmente potrà scalare verso piccole realtà.
MySQL viceversa è ottimo per realtà medio piccole e può scalare benissimo verso grandi realtà.

Per piccole-medie realtà intendo tutte quelle che singolarmente non valgono quasi niente (siti web, portalini, gestionali di piccole ditte, ecc.) ma che assieme fanno un numero di utenti (magari non di capitale) enorme.

Parlo ovviamente dal punto di vista del programmatore: come posso farmi affidare un progetto per un sito, ad es., del valore di 2.000 euro e dire "vi serve Oracle!" ?
D'accordo, ora sarà anche gratis, ma per gestirlo decentemente e lavorarci, occore una preparazione non indifferente, anche solo per usarlo in modo minimale. Per non parlare delle risorse HW.
MySQL, viceversa, è molto intuitivo, poco dispersivo e meno esigente; non penso di essere l'ultimo arrivato nell'IT, ma con Oracle ogni volta è un tribolio solo per ricordarmi come accedere a SQLPlus :(; con MySQL si apre una shell (dos o bash) e con una riga si entra.

Sempre dal punto di vista del programmatore, non mi piacciono molto le stored procedure, perché legano l'applicativo al DB. Non so se ora quelle di MySQL e Oracle siano compatibili, comunque programmando in Java, se non uso le stored procedure, sono sicuro di poter portare il mio programma su DB che non le implementano, altrimenti nisba.

Per questi motivi vedo Oracle come un'ottima scelta di vita, dove c'è dietro una pianificazione e la decisione di affidarsi in tutto a Oracle (eventualmente con ambienti di sviluppo dedicati), sapendo che qualsiasi cosa si farà, difficilmente potrà essere riutilizzata con MySQL (PostgreSQL, ecc.) a seguito di ripensamento.
Compagnie come l'Alitalia, probabilmente non avranno mai questa esigenza.
Una piccola ditta che non potendosi più permettere i costi di licenza di Oracle o di assistenza specializzata, dovesse scegliere di cambiare DB, dovrebbe buttare via molto o implementare soluzioni che "emulino" i comportamenti di Oracle non implementati nel nuovo db.

IMHO

mailand

02-03-2006, 09:24

condivido quasi tutto quello che hai detto pinok salvo la complessità di connessione ad oracle, anche lì basta una stringa ;)

per la scalabilità/compatibilità, secondo me, quando parti con un db qualunque esso sia dopo è veramente micidiale trasporlo in un altro... per esperienza, se sono un bagno di sangue già i cambi di relase, le migrazioni di piattaforme intere sono veramente micidiali :D io sono dell'idea che se si parte con un prodotto , il progetto debba morire con quello ;)

per quanto riguarda le stored procedures, non sono simpatiche nemmeno a me nonostante usi packages a 1000, ma al momento sviluppo in pl-sql applicativi di datawarehousing, e avendo solo insert-select e dovendo integrare tutto mi sembra un'ottima scelta, tanto più che tramite oracle controllo il ciclo di acquisizione dati da server terzi (e molto eterogenei) con un controllo di errore sicuro al 99%, in modo particolare ora che tramite una function oracle gestisco i processi di sistema operativo, i relativi return code e gli errori :)

pippo985

02-03-2006, 11:18

Sempre dal punto di vista del programmatore, non mi piacciono molto le stored procedure, perché legano l'applicativo al DB. Non so se ora quelle di MySQL e Oracle siano compatibili, comunque programmando in Java, se non uso le stored procedure, sono sicuro di poter portare il mio programma su DB che non le implementano, altrimenti nisba.

IMHO

Io preferisco portare il max possibile dentro il DB, perchè per quanto riguarda l'ottimizzazione non c'è paragone.
Vuoi mettere richiamare una storeprocedure che fa select, update, operazioni come un processo interno al contrario di un programma che:
-apri select
-prendi risultato
-elabora
-aggiorna
ed ogni volta c'è un ping pong di dati tra un sistema e l'altro.

mailand

02-03-2006, 12:29

pinok

02-03-2006, 13:15

condivido quasi tutto quello che hai detto pinok salvo la complessità di connessione ad oracle, anche lì basta una stringa ;)

no, no...
Non intendevo la connessione tramite Java o da programma, lì basta davvero una riga e se si usa l'SQL standard per le chiamate al DB non ci sono problemi.
Intendevo la connessione a livello di shell: Oracle è tanto potente e fornito che ti aggiunge una sfilza di voci nel menu, al punto da disorientare e non capire dove passare per arrivare alla shell.

PS: sul portatile (visto che per gli sviluppatori era già gratuito da anni) devo disabilitarlo quando non devo sviluppare per chi ha un DB Oracle, e dire che avevo già minimizzato i servizi attivi e il DB è molto piccolo. Con MySQL mi vanno via solo una 10 MB di ram :)

pinok

02-03-2006, 13:22

Io preferisco portare il max possibile dentro il DB, perchè per quanto riguarda l'ottimizzazione non c'è paragone.
Vuoi mettere richiamare una storeprocedure che fa select, update, operazioni come un processo interno al contrario di un programma che:
-apri select
-prendi risultato
-elabora
-aggiorna
ed ogni volta c'è un ping pong di dati tra un sistema e l'altro.
Ovviamente ogni caso và valutato a parte, di sicuro la tua soluzione diventa monolitica con la tua realtà. Se fai qualcosa di interessante e ti piacerebbe rivenderlo, lo potrai fare solo con realtà simili alla tua e basate su Oracle.

PS: se uno ottimizza le procedure che hai descritto e a seconda della complessità di elaborazione, si potrebbe anche sostenere che usare un programma esterno allegerisce il carico computazionale sul DB (che di suo è ottimizzato più all'I/O che non alla CPU)

pippo985

02-03-2006, 13:33

il tutto con la verosimile complicanza di faticare non poco per capire in quale punto del tuo processo si è verificato l'errore ;)
simpatia o meno, bisognerebbe sempre guardare alla praticità ;)

Ossia, inserendo una gestione dell'errore all'interno di una storeprocedure, non vedo come non puoi trovare l'errore o il punto dove si blocca. :D :D :D

pippo985

02-03-2006, 13:45

Ovviamente ogni caso và valutato a parte, di sicuro la tua soluzione diventa monolitica con la tua realtà. Se fai qualcosa di interessante e ti piacerebbe rivenderlo, lo potrai fare solo con realtà simili alla tua e basate su Oracle.

Vabbè, non è che quando sviluppi un'applicazione poi lo cambi il DB frequentemente. O sbaglio? Delle applicazioni che hai sviluppato quante volte poi hai cambiato DB?
Se usi Oracle ad esempio, ci sono tante di quelle funzioni interne che puoi utilizzare in una semplice query che portate su un altro DB andrebbero in errore, quindi un porting lo dovresti cmq fare

PS: se uno ottimizza le procedure che hai descritto e a seconda della complessità di elaborazione, si potrebbe anche sostenere che usare un programma esterno allegerisce il carico computazionale sul DB (che di suo è ottimizzato più all'I/O che non alla CPU)

Se questo che dici fosse vero allora io quando faccio una select e voglio ordinare per un campo, dovrei scaricarmi tutto il risultato in locale e poi fare l'ordinamento. Giusto? :doh:

pinok

02-03-2006, 14:02

Non hai capito, o non vuoi capire...
Vabbè, non è che quando sviluppi un'applicazione poi lo cambi il DB frequentemente. O sbaglio? Delle applicazioni che hai sviluppato quante volte poi hai cambiato DB?

Mi è già capitato, e comunque la cosa è molto più frequente di quello che pensi se fai applicativi esterni a un DB, che quindi sono e devono essere esterni al DB.
Quello che dicevo è che se fai una cosa interessante per la tua realtà (ad es. una particolare gestione dei ticket dell'help desk) e poi ti accorgi che potrebbe essere utile ad altri, potrai rivenderla solo a chi ha Oracle.
Se avessi fatto il tutto senza le stored procedure, la potresti rivedere a tutti.

Se usi Oracle ad esempio, ci sono tante di quelle funzioni interne che puoi utilizzare in una semplice query che portate su un altro DB andrebbero in errore, quindi un porting lo dovresti cmq fare

Anche quelle ti legano le mani, come dici tu, confermando che se da un lato Oracle è un pregevole prodotto, dall'altro è un virus: se ci entri, non puoi uscirne ;)

Se questo che dici fosse vero allora io quando faccio una select e voglio ordinare per un campo, dovrei scaricarmi tutto il risultato in locale e poi fare l'ordinamento. Giusto? :doh:
Non vuoi capire: il DB è ottimizzato per determinati tipi di operazioni, dicendo I/O non volevo elencarli tutti. Ovvio che è ottimizzato per select, insert e altro.
Se però la stored procedure, dopo avere raccolto i dati molto velocemente (e vorrei capire quanto più velocemente di un applicativo esterno se poi si basa su delle select che con preparedStatement di Java verrebbero demandate comqunque al DB) si infila in una elaborazione pesante, credi che il DB Admin sarebbe contento, o preferirebbe che queste cose fossero elaborate all'esterno?
Se ci sono 100 client che devono avvalersene (metti una ditta con le filiali), è meglio attivare 100 stored procedure sul server, o avere un server web (o più server web) esterni che sparano tante select, ma elaborano per conto loro?
Sono cose ovviamente da studiare a tavolino caso per caso, ma a priori non si può dire che la stored procedure sia una panacea e, purtroppo, ti devo dire che a volte l'ho vista usare come un tapullo all'incapacità di fare diversamente determinate operazioni o per mascherare una progettazione non ottimale del DB.
IMHO

mailand

02-03-2006, 14:36

Ossia, inserendo una gestione dell'errore all'interno di una storeprocedure, non vedo come non puoi trovare l'errore o il punto dove si blocca. :D :D :D
esatto :D

dupa

02-03-2006, 14:39

nessuno l'ha citato, però postgre, è opensource, GPL e ha praticamente la stessa qualità di Oracle.

mailand

02-03-2006, 14:49

Non hai capito, o non vuoi capire...

Mi è già capitato, e comunque la cosa è molto più frequente di quello che pensi se fai applicativi esterni a un DB, che quindi sono e devono essere esterni al DB.
Quello che dicevo è che se fai una cosa interessante per la tua realtà (ad es. una particolare gestione dei ticket dell'help desk) e poi ti accorgi che potrebbe essere utile ad altri, potrai rivenderla solo a chi ha Oracle.
Se avessi fatto il tutto senza le stored procedure, la potresti rivedere a tutti.

Anche quelle ti legano le mani, come dici tu, confermando che se da un lato Oracle è un pregevole prodotto, dall'altro è un virus: se ci entri, non puoi uscirne ;)

Non vuoi capire: il DB è ottimizzato per determinati tipi di operazioni, dicendo I/O non volevo elencarli tutti. Ovvio che è ottimizzato per select, insert e altro.
Se però la stored procedure, dopo avere raccolto i dati molto velocemente (e vorrei capire quanto più velocemente di un applicativo esterno se poi si basa su delle select che con preparedStatement di Java verrebbero demandate comqunque al DB) si infila in una elaborazione pesante, credi che il DB Admin sarebbe contento, o preferirebbe che queste cose fossero elaborate all'esterno?
Se ci sono 100 client che devono avvalersene (metti una ditta con le filiali), è meglio attivare 100 stored procedure sul server, o avere un server web (o più server web) esterni che sparano tante select, ma elaborano per conto loro?
Sono cose ovviamente da studiare a tavolino caso per caso, ma a priori non si può dire che la stored procedure sia una panacea e, purtroppo, ti devo dire che a volte l'ho vista usare come un tapullo all'incapacità di fare diversamente determinate operazioni o per mascherare una progettazione non ottimale del DB.
IMHO

ovvio che ogni caso va analizzato, ci sono apposta gli analisti... ;) sennò che mi pagano a fare, per 2 report e 4 procedure??? :D

e comunque ho visto cani sviluppare in pl/sql e cani sviluppare in java (o in .net, vb, c e chi più ne ha più ne metta) andando in entrambi i casi a demolire dei db studiati funzionalmente bene e cambiarne logiche consolidate per "vezzi" che venivano giustificati da interfacce utente ignobili...
altri che con una singola stored procedure riducono tempi di elaborazione di tabelle da 4 ore a 9 minuti, senza modifcare nulla di esistente...

quo dicto, non voglio accusare nessuno e dire che una metodologia è migliore di un'altra. solo, bisogna considerare CHE COSA SI VUOLE DAVVERO e qual'è la via più agile/veloce/sicura su come ottenere i dati...
in web quasi sicuramente non potrai usare il client oracle locale, in un transazionale (tipo coop o lottomatica, in generale un retail con casse) farai molta fatica a usare un applicativo web: la scelta è dettata dalla necessità :D

per quanto riguarda la rivendibilità, secondo me il discorso si fa più ampio, e si andrebbe troppo ot... e preferisco non sbilanciarmi, diventerei inutilmente polemico ;)

il tutto ovviamente IMHO :)

pippo985

02-03-2006, 17:40

Non hai capito, o non vuoi capire...

Mi è già capitato, e comunque la cosa è molto più frequente di quello che pensi se fai applicativi esterni a un DB, che quindi sono e devono essere esterni al DB.
Quello che dicevo è che se fai una cosa interessante per la tua realtà (ad es. una particolare gestione dei ticket dell'help desk) e poi ti accorgi che potrebbe essere utile ad altri, potrai rivenderla solo a chi ha Oracle.

Evidentemente utilizziamo db in ambiti diversi, quindi abbiamo anche una concezione diversa del modo di utilizzarli.
Ti posso assicurare che se vuoi ottimizzare un sistema devi PER FORZA utilizzare quello che il DB ti offre in termini di ottimizzazione. Questo comporta per contro un porting in caso di cambio db.

Non vuoi capire: il DB è ottimizzato per determinati tipi di operazioni, dicendo I/O non volevo elencarli tutti. Ovvio che è ottimizzato per select, insert e altro.
Se però la stored procedure, dopo avere raccolto i dati molto velocemente (e vorrei capire quanto più velocemente di un applicativo esterno se poi si basa su delle select che con preparedStatement di Java verrebbero demandate comqunque al DB) si infila in una elaborazione pesante, credi che il DB Admin sarebbe contento, o preferirebbe che queste cose fossero elaborate all'esterno?

Che centra non ti sto mica dicendo che la store procedure devi recuperare un valore da una tabella e deve fare 4.000.000.000 di operazioni aritmentiche per calcolare il peso della Terra nel caso in cui la sua circonferenza fosse 1,53 volte più grande del Sole.

Se ci sono 100 client che devono avvalersene (metti una ditta con le filiali), è meglio attivare 100 stored procedure sul server, o avere un server web (o più server web) esterni che sparano tante select, ma elaborano per conto loro?
Sono cose ovviamente da studiare a tavolino caso per caso, ma a priori non si può dire che la stored procedure sia una panacea e, purtroppo, ti devo dire che a volte l'ho vista usare come un tapullo all'incapacità di fare diversamente determinate operazioni o per mascherare una progettazione non ottimale del DB.
IMHO
La store procedure sarebbe di gran lunga più veloce e meno pesante perchè potrebbero sfruttare anche eventuale un piano di esecuzione già costruito :cool: :cool: :cool:

Quello che poi hai visto tu sulle store procedure è un altro discorso... :fagiano: :fagiano: :fagiano:

shinya

02-03-2006, 19:08

Nightingale

03-03-2006, 11:33

Io sono un pò newbie con oracle (uso pl/sql da 1 mesetto) ma quello delle stored procedure mi sembra un meccanismo dal quale non si può prescindere per grosse applicazioni. A parte le performance guadagnate, ma anche la sicurezza è un fattore importante. Si pensi solo al pericolo di sql injection nel gestire le query direttamente.
Noi stiamo sviluppando una serie di applicativi per Coop Italia, e usiamo stored procedure a secchiate proprio :)

Allora o sei un collega, o sei alla concorrenza... :D
Comunque sì, sottolineo anche io come le stored procedure, packages in primis, siano praticamente essenziali per applicativi di un centro calibro. Il PL/SQL è troppo comodo.