Newsgroup: it.comp.www.php
Titolo: [OT] MySQL e motore da usare...

Salve,
 
sono lontanto da MySQL da circa un paio d'anni ed ora mi piacerebbe 
riprenderlo per terminare un piccolo database per gestire alcune 
matricole dell'ufficio.
 
Il "progetto" che avevo creato a suo tempo prevedeva l'uso di INNODB che 
utilizzavo per le FK; usando quel motore avevo creato tabelle piccole 
concatenate tra loro con al massimo 10 colonne ciascuna perchè avevo 
letto in giro della necessità di creare "tabelle piccole".
 
Se qualcuno di voi ha modo di aggiornarmi in merito intanto ovviamente 
continuerò a cercare su Google ulteriori info sulle "novità" legate a 
questo db.
 
Saluti.
GbMax78

 letto in giro della necessità di creare "tabelle piccole".
 
E` ancora necessario usare InnoDB per le FK, ma questa storia delle 
tabelle piccole non l'avevo mai sentita.
 
Ho un DB su InnoDB con un centinaio di tabelle, molte con oltre una 
cinquantina di campi anche grossi (dell'ordine di 100-200 KB per riga) 
che non ha problemi di sorta.
 
Ma io per questo tipo di cose consiglio PostgreSQL.
 
Bye.

 Ma io per questo tipo di cose consiglio PostgreSQL.
 
Io ho un server L.A.M.P. ed ho sempre usato questi accoppiamenti, ho 
sentito parlare girando per la rete di PostgreSQL ma non l'ho mai 
provato e per ora non ne conosco il tipo di licenza, la compatibilità 
con Linux etc. dovrò studiarmelo un pò...
 
Saluti !
GbMax78

 con Linux etc. dovrò studiarmelo un pò...
 
La licenza e` BSD, se non ricordo male.
La compatibilita` con Linux... direi massima. :)
 
E` forse un po' piu` complesso di MySQL a livello amministrazione 
(permessi degli utenti, permessi di accesso, ecc.), ma e` anche molto piu` 
potente e standardizzato.
 
Bye.

 potente e standardizzato.
 
Mysql è (da quel che ne sò) il db rdbms che risente meno l'effetto del
SO, installato su linux o windows è praticamente uguale, mentre
postgres da linux (ottimo) a windows soffre parecchio (mi domando se
qualcuno lo usa davvero in produzione su macchina windows).
 
Di postgres apprezzerai sicuramente la shell interattiva psql (se la
usi): una volta imparati i comandi, è molto più rapida e funzionale di
quella di mysql.
 
 
Per gestire le foreign keys, indipendendemente dal db, prova a dare
un'occhiata a SquirrelSql: è un ottimo tool visuale che permette anche
alcuni benchmark (semplici)

 tabelle piccole non l'avevo mai sentita.
 
Ho trovato questo link 
http://www.stardata.it/wp-content/uploads/2009/09/lc64_mysql_schemi_partizionamento.jpg
 
dove si parla di partizionamento orizzontale e verticale, grazie alle FK 
ho diviso una "grande" tabella in due tabelle.
 
Diciamo che leggendo sempre l'articolo 
http://www.stardata.it/le-novita-di-mysql-5-1-186/
 ho letto di una nuova 
tecnica "automatica" del db per dividere in maniera orizzontale 
impostando un range ogni "tot" numero di dati, molto interessante.
 
Saluti.
GbMax78

InnoDB limita il contenuto massimo di una riga a 8Kb circa*; con tabelle
che hanno molte colonne, in particolar modo varchar, si rischia di
superare il contenuto massimo della riga. Questo perchè di un varchar
mysql mette "in riga" fino a 768 bytes, quindi una tabella come questa:
 
create table test (
field_01  varchar(1000),
field_02  varchar(1000)
field_03  varchar(1000),
field_04  varchar(1000)
field_05  varchar(1000),
field_06  varchar(1000)
field_07  varchar(1000),
field_08  varchar(1000)
field_09  varchar(1000),
field_10  varchar(1000)
field_11  varchar(1000),
) Engine=InnoDB;
 
regge il carico finchè non vengono scritti almeno 768 caratteri** in
tutte le colonne (768*11=8448); quando questo succede, la riga non viene
inserita e il db ritorna un errore
 
ERROR 1030 (HY000) at line 1: Got error 139 from storage engine
 
Le possibili soluzioni in questo caso sono la suddivisione della tabella
in due tabelle separate (collegate tramite chiave) e l'introduzione di
campi text o blob, tenendo presente però che anche per i text/blob
vengono salvati in riga i primi 768 caratteri (e quindi avrebbe senso
riunire uno o più campi varchar in un singolo text/blob).
 
Limiti simili sono presenti per l'indicizzazione e per la lunghezza
massima (da non confondere con il contenuto massimo) di una riga (65Kb).
 
Note:
* in realtà è relativo alla dimensione della page sul db; con un default
da 16kb il contenuto massimo di una row è di 8126 bytes.
** se utilizzate un charset con codifica a lunghezza variabile (UTF-8 ad
esempio) ovviamente il numero di caratteri sufficienti per "rompere" una
riga diminuisce.
 
Riferimenti:
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html
 
http://www.mysqlperformanceblog.com/2011/04/07/innodb-row-size-limitation/
 


 superare il contenuto massimo della riga.
 
Le tabelle con molte colonne solitamente sono la spia di un database non
normalizzato. La soluzione è disegnare correttamente il DB.
 
	Y.

 normalizzato. La soluzione č disegnare correttamente il DB.
 
Esatto, era quello che pensavo anche io! :D
 
-- 
http://www.evilripper.net
 
http://www.flickr.com/photos/evilripper/
 

 Le tabelle con molte colonne solitamente sono la spia di un database non
