Newsgroup: it.comp.os.linux.development
Titolo: Postgres: varchar o text

Sto facendo un programma che deve tra le altre cose memorizzare dei
dati anagrafici in un database SQL.
Per campi come nome e cognome, idirizzo, città...ecc. sono incerto se
usare varchar(...) o text.
Il migliore sembrerebbe text, però temo che abbia un impatto molto
pesante sulle prestazione del server SQL.
Voi cosa dite?
Grazie, ciao,
Lumaca
lum...@writeme.com
ICQ: 12424362

 pesante sulle prestazione del server SQL.
In quanto a prestazioni, la differenza e` tra campi a lunghezza fissa
(char) e variabile (varchar, text). In particolare, avere una colonna a
lunghezza variabile, text o varchar che sia, rende piu` pesante
l'accesso a tutte le colonne seguenti (quindi sarebbe bene usarne una
sola e lasciarla per ultima).
Ciao
 David
-- 
<d.santinoli presso mi. flashnet. it>

pesante sulle prestazione del server SQL.
Il problema e' che o usi char o usi varchar. Il secondo e' piu' pesante,
ma d'altra parte puo' occupare meno spazio.
Potrebbe essere utile codificare la localita' - se hai un gran numero di
elementi, il gioco vale la candela, specie per le ricerche.
Anagrafica
{
	nome		char(32)
	cognome		char(32)
	indirizzo	char(64)
	localita	int4
	telefono	int4
	...
}
Localita
{
	localita	int4
	cap		int4
	prefisso	int4
	testo		varchar(128)
}
Giudica tu se ti conviene usare char o varchar per nome e cognome. Per
quanto riguarda l'indirizzo, potresti anche codificarlo
	ind_pref	int4	(via,piazza,viale,largo,vico,calle...)
	ind_codice	int4
	civico		int4
	ind_cpost	char(4)
Naturalmente, questo ha senso se hai TANTI nomi raggruppati: invece di
immettere trecento volte VIA DELL'ARGINGROSSO NNN immetti per trecento
volte (2,10020,NNN,''). In ricerca va molto piu' veloce, dopo una fase
in cui decodifichi l'indirizzo.
Per tabelle piccole, stiamo discutendo del sesso degli angeli 8-D
Leonardo
".signature": bad command or file name

sola e lasciarla per ultima).
Mmh, grazie del consiglio.
Mi sa che userò soprattutto char, allora.
Ciao,
Lumaca
lum...@writeme.com
ICQ: 12424362

Per tabelle piccole, stiamo discutendo del sesso degli angeli 8-D
Grazie, per le utili info.
Sto database ha circa 60 campi e dovrebbe arrivare anche oltre i 3000
record!! (scusa ma sono abituato con dbase/clipper, avrei dovuto dire
attributi e tuple, giusto?).
Intanto ho piazzato quasti tutti char e due text, perchè è un
programma grosso e vorrei farlo funzionare in breve tempo.
Vabbè, ti svelo il segreto 8-0, serve per la gestione di uno studio
dentistico!


programma grosso e vorrei farlo funzionare in breve tempo.
:-)
mysql> SELECT preferred FROM mytest WHERE anag IN (234567,12,356,182);
+-----------+
| preferred |
+-----------+
| nobody    |
| nobody    |
| nobody    |
| nobody    |
+-----------+
4 rows in set (0.07 sec)
mysql> UPDATE mytest SET username='barney' WHERE username='fred';
Query OK, 10000 rows affected (3.45 sec)
Rows matched: 10000  Changed: 10000  Warnings: 0
Non e' un Cray XMP. E' un Pentium 166 con kernel e MySQL ottimizzato, ed
un hard disk EIDE 5400 cui ho tirato il collo con hdparm.
Sono sicurissimo che si puo' fare di meglio.
Il tuo database di 3000 clienti, se lo puppa in un secondo e 3 centesimi
abbondanti.
Avrei un database anche piu' grosso (poco piu' di un gigabyte), pero' e'
sulla macchina di produzione, e ora sono a casa.
