Newsgroup: it.comp.os.linux.sys
Titolo: [OT] Oracle free? seee come no.

Per essere corretto e tantinello masochista, rettifico un commento data ad
una personale che chiedeva informazioni sull'uso di mysql in ambito
commerciale.
Il commento era che oracle aveva rilasciato il db 10g (beta) in versione
free.
Peccato che la versione definitiva è free ancora, ma solo per lo sviluppo (e
neanche del tutto), per qualsiasi altra minima cosa costa almeno 5000$ per
server o 150$ per connessione al db.
In compenso è liberamente scaricabile ( :P ) ed è dotata del magnifico e
incomparabile universal installare (400Mb di pacchetti java e robetta
varia, e 100/200Mb di db, più o meno la stessa cosa per installare il
driver odbc dal lato client win).
E con la sparizione del pacchetto rpm che installava e configurava tutto da
solo il db.
In compenso il controllo della configurazione della macchina lo fa ancora
parecchio bene e con una buona dose di informazioni.

 solo il db.
Mai saputo, non è che ti riferisci al pacchetto orarun di SuSE?
(e comunque, su una distribuzione certificata, installare Oracle è una cosa
in genere molto semplice).
-- 
Per rispondermi, togli il nome del poeta

 server o 150$ per connessione al db.
Oracle XE (yikes-e)
http://www.oracle.com/technology/products/database/xe/index.html
cit:
Oracle Database 10g Express Edition
Free to develop, deploy, and distribute
ma io resto ancora fedele all'HSQLDB! :)
ciao!
gl

 server o 150$ per connessione al db.
Waitamminute:
  - c'è il solito Oracle Standard Edition, che è scaricabile ed
    utilizzabile gratuitamente per lo sviluppo (ma non per l'uso in
    produzione).
  - e poi c'è Oracle Express Edition (detta anche "Oracle XE", per ora
    solo in beta), che è limitata a 4GB di dati, 1GB di memoria, 1 CPU e
    una sola istanza per host, ma che puoi usare gratuitamente per gli
    scopi che vuoi. Ed è probabile che sarà così anche per la versione
    definitiva.
Per cui, il discorso "Oracle gratuito" si riferisce più che altro alla 
versione Express.
Il tutto probabilmente nasce dal fatto che PostgreSQL e Firebird si 
stanno letteralmente mangiando la fascia dei mediopiccoli, e che Oracle 
non può fare con loro come ha fatto con MySQL (ha recentemente acquisito 
InnoDB, l'azienda che produce l'unico backend decente per MySQL).
-- 
  (\_/)   |   \    \  | ___|_   |_   |   /\/\  ianezz a casa sua... :-)
  (^.^)   |  _ \  | \ | _|     /    /   {^.^ } Verba volant, scripta
/(")(") _|_/  _\_|  _|____|____|____| (")(")\ manent, data corrupted

 ma io resto ancora fedele all'HSQLDB! :)
Vuoi un consiglio? Butta HSQLDB
Henryx


ah, beh, il solito commento "all'italiana".
quake o unreal?
juve o inter?
una cosa così, insomma, come quello che si legge sui forum di punto
informatico.
comunque no grazie, le applicazioni girano benissimo e da tutti i test
(fatti da me sulle mie applicazioni) è più veloce di Postgres e Mysql.
se tu hai avuto una ragione per non usare HSQLDB, qualunque essa sia, non
si applica al caso dei miei applicativi e delle esigenze dei miei clienti.
augh! :)
gl

 InnoDB, l'azienda che produce l'unico backend decente per MySQL).
Beh, sarà anche in fase di forte sviluppo ma il backend NDB funziona 
alla perfezione.
-- 
Ciao da Villo  -  GPG public key available
                   Ferrara Linux Users Group
Remove +settanta for email replies

 
ah si? allora forse già che siamo OT puoi aiutarmi a risolvere un problema che ho avuto con hsql
ti riporto un posto che avevo mandato su .db qualche settimana fa
per riassumere, il problema è che con tanti record hsql diventa moooolto lento.
confermi o sbaglio qualcosa?
ecco il post:
ciao a tutti volevo realizzare una applicazione java e sfruttare hsql che ho già usato varie volte per tabelle "piccole".
ora devo utilizzare una tabella grande con 300k record circa e fare un'applicazione stand-alone che deve girare su win.
prima di procedere ho fatto un test di velocità ma mi sono bloccato.
se eseguo queste query:
--istantanea
CREATE TEXT TABLE binding_txt (
    id_persona char(20),
    nome varchar(255),
    cognome varchar(255),
    via  varchar(255),
    num_civico  varchar(255),
    cap  char(5),
    citta  varchar(255),
    provincia  char(2),
    codice  varchar(255)
);
\p Setting text file source
--ci mette alcuni minuti(5/10), il file contiene 300000 righe circa
SET TABLE binding_txt SOURCE "dicembre.txt;ignore_first=true;quoted=false;fs=\semi";
--ci mettono mooooolti minuti in più (10/20/-->infinito)
create index nomecogn on binding_txt(nome, cognome);
alter table binding_txt add PRIMARY KEY(id_persona);
inoltre se creo una tabella cached e ci inserisco le stesse linee, il db
viene creato, gli indici ci mettono comunque vari minuti, ma la cosa
drammatica è che l'apertura del db "pieno" è lentissima (10/20 minuti).
ora, il mio hardware non è aggiornato, (pIII 512 Mb ram / linux + xfce4)
ma non ho mai avuto problemi a sviluppare. ho visto che tra le faq si
segnala ( 
http://hsqldb.org/web/hsqlFAQ.html#BIGRESULTS
 )
di non creare recordset grandi, ma qui il problema è proprio ad aprire il db.

 di non creare recordset grandi, ma qui il problema è proprio ad aprire il db.
ti consiglio di lavorare un po' coi parametri della Java VM (-Xmx -Xms,
vedi 'java -X').
Io in questo preciso momento sto lavorando su un applicativo con DB di
9,1MB su filesystem e parametri standard della VM (una decina di tabelle
cached e una trentina di tabelle memory)
Query molto grosse sono state ottimizzate con indici e join solo
dove necessario.
Fermare e riavviare il server HSQLDB non richiede più di questo tempo
misurato con time (3 volte)
real    0m0.029s
user    0m0.000s
sys     0m0.000s
real    0m0.003s
user    0m0.004s
sys     0m0.000s
real    0m0.003s
user    0m0.000s
sys     0m0.004s
Richiede più tempo alla chiusura, anche se non sono state fatte modifiche
(comunque ho settato WRITE_DELAY 10)
real    0m2.462s
user    0m0.480s
sys     0m0.064s
real    0m1.863s
user    0m0.388s
sys     0m0.060s
real    0m2.026s
user    0m0.376s
sys     0m0.056s
La macchina è un IBM P4 HT da 3.0GHz con 512MB di RAM.
La macchina inoltre è stracarica di lavoro (distribuisce GNOME ai client
via X -query, eclipse, 
openoffice.org
, ecc...)
di più, nin zò.
ciao
gl

 si applica al caso dei miei applicativi e delle esigenze dei miei clienti.
La ragione per cui dico di non usarlo, sono da ricercare nei seguenti
motivi:
- Sotto windows esegue un locking dei file del database tale che l'unico
  modo di sbloccarli, nel caso in cui il processo termini male, e` riavviare
  il sistema operativo (no, non e` un bug di windows);
- Attualmente, il livello di isolamento della transazione è di tipo READ
  UNCOMMITTED. Cio` significa che, avendo due o piu` sessioni contemporanee
  al database, la sessione due vede tutti i casini che sta facendo la
  sessione uno anche se questa non ha eseguito alcun commit e l'autocommit
  e` impostato a false (per dovere di cronaca, nella versione di sviluppo,
  stanno aggiungendo un altro livello di isolamento delle transazioni);
- Per default (da leggere: non e` un bug, e` una feature) non viene eseguito
  alcun controllo sulla dimensione dei valori di un campo (e.g. posso
  mettere in una colonna definita come VARCHAR(10) una stringa di 11
  caratteri). Sempre per dovere di cronaca, questo comportamento e`
  modificabile tramite properties.
Infine, c'e` da dire che il file .data (creato nel momento in cui vengono
definite delle tabelle di tipo CACHED) ha il difetto di gonfiarsi a
dismisura finquando non viene fatto un CHECKPOINT DEFRAG o uno SHUTDOWN
COMPACT (ok, non e` un grosso problema, ma puo` risultare abbastanza
fastidioso).
In definitiva, per parere personale, HSQLDB e` ottimo nei casi in cui venga
utilizzato in modalita` embedded o nei casi in cui il server non abbia piu`
di una connessione simultanea. Per tutti gli altri casi, molto meglio
rivolgersi ad altri database
Henryx
P.S. tengo a precisare che queste cose l'ho sperimentate sulla mia pelle e
che, soprattutto nel caso del livello di isolamento della transazione, ho
avuto dei casini indicibili

 cosa in genere molto semplice).
Su che non sia più un suicidio concordo, ma sul semplice e sul molto non mi
sento propenso a concordare.
Lasciando poi perdere la camionata di parametri, autorizzazioni, ruoli, che
per ogni db si può (e in parte si deve) configurare.

 per ogni db si può (e in parte si deve) configurare.
Quella è una cosa che lasciavo sempre ai DBA, io come sistemista gli facevo
vedere che "connect / as sysdba" funzionava e poi tanti saluti :)
