Newsgroup: it.comp.software.database
Titolo: opinioni a confronto

Sulla base delle vostre esperienze, potreste indicare
debolezze, punti di forza e un giudizio complessivo
sui DB più o meno free?
- Derby
- Firebird
- HSQLDB
- MS SQL Server 2005 Express
- MySQL
- Oracle 10g Express
- PostgreSQL
- Altro ...

 - Firebird
PRO: continuo sviluppo, stabile, integrità referenziale (altri mi pare non
ce l'abbiano)
CONTRO: non supporta alcune funzioni (risolvibile più o meno con le udf),
non supporta SELECT di SELECT, non supporta UPDATE a catena (un po' il
concetto dele INSERT FROM SELECT che invece supporta).
Ovviamente AFAIK, se ci sono stati sviluppi ulteriori non lo so.

 ce l'abbiano)
Vuoi dire che Oracle e MS SQL Server non hanno integrità referenziale?

 Vuoi dire che Oracle e MS SQL Server non hanno integrità referenziale?
No volevo dire che alcuni di quelli sulla lista mi *sembra* di no, ad
esempio per MySQL l'avevo letto da qualche parte.
Ovviamente avendo risposto solo a "Firebird" vuol dire che conosco
direttamente solo quello fra quelli citati.
Ciao

Andrea [Work] ha scritto:

MySQL non ha un unico formato di tabella (ENGINE), ma ne ha diversi a
seconda delle funzionalità e delle performance che si vogliono avere.
Nell'engine InnoDB MySQL supporta integrità referenziale, transazioni e
recovery a caldo.
Dalla versione 5 ci sono anche:
- stored procedures/functions (SQL::2003 compliant)
- cursori
- trigger
- views
- prepared statement
- information schema (il database di metadata)
- SQL_MODE (possibilità di influenzare/decidere il modo di funzionamento
del server)
Inoltre, ma già dalla versione 4:
- subqueries
- supporto charset/collation (definibile fino a livello di singola colonna)

 del server)
potresti dire qlc in piu' su questo, se ti va?
grazie
Rob

orsopoeta ha scritto:

Ad esempio nel suo funzionamento di default (senza nessun sql_mode 
abilitato) MySQL gestisce gli inserimenti di valori fuori range o errati 
  senza dare un errore ma facendo un arrotondamento
vedi esempio
corra@localhost[test]> select @@sql_mode;
+------------+
| @@sql_mode |
+------------+
|            |
+------------+
1 row in set (0.00 sec)
corra@localhost[test]> create table prova(a tinyint unsigned);
Query OK, 0 rows affected (0.03 sec)
corra@localhost[test]> insert into prova values(2000);
Query OK, 1 row affected, 1 warning (0.00 sec)
corra@localhost[test]> select * from prova;
+------+
| a    |
+------+
| 255  |
+------+
1 row in set (0.00 sec)
corra@localhost[test]> SET sql_mode='traditional';
Query OK, 0 rows affected (0.00 sec)
corra@localhost[test]> insert into prova values(2000);
ERROR 1264 (22003): Out of range value adjusted for column 'a' at row 1
Con sql_mode disabilitato l'inserimento del valore 2000 in un campo 
TINYINT UNSIGNED (il cui valore massimo è 255) non da' errore ma viene 
arrotondato al valore massimo disponibile (cioè 255). L'operazione )con 
arrotondamento) viene eseguita.
Con SQL_MODE impostato a TRADITIONAL, invece, gli inserimenti fuori 
range vengono considerati degli errori e l'operazione non procede.
Esistono decine di valori per SQL_MODE, uno non consente ad esempio 
l'inserimento di date tipo '0000-00-00', un altro non consente le 
divisioni per zero e così via.
Per ulteriori dettagli e l'elenco di tutti i valori di SQL_MODE vedi qui
http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

Non conosco i primi tre della lista ma tra gli altri opto sempre per 
Postgres, perché è veramente gratuito (a differenza di MySQL), ben 
supportato dai principali ambienti di sviluppo ed è molto potente. Non 
ha quindi nulla da invidiare agli altri della lista.
Certo, ogni situazione ha il suo DB ideale. Per dire, se l'applicazione 
è semplice, Access non è malvagio, anzi!
Alex.

Cosimo Piceno ha scritto:

Io di solito tendo ad usare SQLite o PostgreSQL, a seconda delle esigenze.
Saluti  Manlio Perillo

 range vengono considerati degli errori e l'operazione non procede.
che utilità ha un approccio del genere?


se sql_mode non è impostato devi essere pienamente a conoscenza dei 
meccanismi di arrotondamento perchè in caso di funzionamenti strani la 
fase di debugging può risultare difficile e/o frustrante
il vantaggio è che le query di inserimento/update vanno sempre 
(ovviamente a parte errori di sintassi)
con sql_mode impostato a TRADITIONAL hai un controllo più stringente sui 
valori di input, non rischi di avere un DB con dentro dati strani o 
indesiderati, lo svantaggio è che le query possono terminare con un errore
personalmente non ritengo una modalità meglio dell'altra, tutto dipende 
da quello che si vuole ottenere e dal grado di competenza che si ha nel 
realizzare gli applicativi che si interfacciano al DB