Newsgroup: it.comp.www.php
Titolo: Grosso database

Salve,
un cliente mi ha chiesto di fargli il database per il suo catalogo.
Tenendo conto che ogni articolo ha circa 100 voci (40 circa di VARCHAR e 60 
circa con possibilità SI/NO) e che ci saranno 150-200, pensate che il DB 
sarà lento e mi conviene convincerlo a eliminare qualche voce?
Tenendo conto che impazzirò a fargli un interfaccia di inserimento articoli 
su misura.
-- 
»» TEHO ««

Teho Gamaweb wrote:

ROTFL, questo è minuscolo!! qualsiasi rdbms se la mangia una configurazione 
del genere (se programmata bene).
un grosso database ha diverse centinaia di tabelle da diversi milioni di 
record...
consiglio: non fare un tabellone unico ma splitta in + tabelle. 100 colonne 
per tabella sono tante!
anzi, se riesci ad avere le voci in 'verticale' sarebbe meglio:
una tabella 'articoli', una tabella 'voci' e due coi valori (una per valori 
testuali, l'altra per i flags, IMO).
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://groups.google.com

 
Non dirlo troppo in giro che secondo te questo è "grosso", che non ci 
passi troppo bene ;-))
Certo, meglio pensare a una struttura vispa e almeno un po' normalizzata 
che fare una tabellona con 100 campi inline di cui 60 binari... un po' 
come ti suggerisce punkarruso.
Ciao!
-- 
Fabrizio "Hermooz" Ermini (FI)
Su BMW F 650 GS "Kandarino"

 sarà lento e mi conviene convincerlo a eliminare qualche voce?
Non dirlo troppo in giro che secondo te questo è "grosso", che non ci 


su misura.
Secondo me, se fai come dice punkarruso, con una tabella "articoli", una
tabella "attributi" e una tabella "valori", anche l'interfaccia ti viene
messa benino. Magari anche una interfaccia "attrtype" con i tipi di ogni
attributo.
Prova a pensare di fare una tabella
	idattr		ID
	attributo	varchar
	attrtype	integer
	default_val	varchar
	regexp_ok	varchar
	errormsg	varchar		// Se vuoto, un msg di default
	descr_IT	varchar		// Descrizione dell'attributo
	idattrtype	varchar		// Inutile tenerlo integer...
	htmlinsert	varchar		// HTML per l'inserimento
	htmlclose	varchar
	has_size	boolean
	has_value	boolean
...praticamente poi l'interfaccia la puoi fare con un ciclo sul database
e aggiornarla dinamicamente.
	INSERT INTO attributi ...
	( 'Soggetto a IVA', 'CHECKBOX', '1', NULL, NULL, 'Marcare la
casella se l''articolo e'' soggetto ad aliquota IVA');
	INSERT INTO attrtype
	( 'CHECKBOX', '<INPUT TYPE="TEXT"', '', 1, 1, ... );
Radio, textarea, combo, multiselect, select, text, password... se arrivi
a dieci tipi, e' tanto. Metti pure un Kb a riga: sono 10 Kb.
Gli attributi sono 200. Diciamo 200 Kb, e ci stai veramente largo.
200 articoli, nemmeno qui si superano i 200 Kb.
Poi 200 x 150 "valori" che richiedono un ID articolo (4 bytes), un ID di
attributo (4 bytes), varie altre info di colonna (8 bytes?), e infine il
valore, mediamente 3-4 bytes - il si' o no si puo' mappare su NULL e '',
per cui occupa due byte proprio a sprofondare. E sono 20 bytes per 30000
righe, totale 600 K.
Esageriamo e raddoppiamo per tener conto degli indici? Siamo a due mega.
Altro che grosso... questo database qui ci sta su un Palm Pilot :-) e va
come le palle di fņo.
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.

Beh... il dbase è grosso... se hai un hosting su PDP-11 hi hi hi... dai
scherzo... è natale... un pò di allegria :))))

Grazie x i consigli, cmq il "grosso" era proporzionato alla per ora mia 
bassa conoscenza di DB ;)