Newsgroup: it.comp.software.database
Titolo: MySQL design

Ho nuovamente un 'problema' con MySQL...
Sto lavorando a una web application e non ho a disposizione le InnoDB,
devo quindi fare a meno dell'integrità referenziale. Il mio problema è
che cerco come sempre di contenere le tabelle e in qualsiasi modo
organizzo la base di dati sono insoddisfatto.
Devo organizzare dei prodotti 'copiando' da un sito web americano (i
siti *devono* essere uguali). Li i prodotti vengono divisi in un gruppo
e in un sottogruppo: ad ogni gruppo corrispondono diversi sottogruppi, a
cui corrispondono diversi prodotti. Ovviamente non ho assolutamente
nulla dagli sviluppatori del sito gemello, nemmeno l'organizzazione del
database, che devo dedurre guardando il sito.
CREATE TABLE Groups (
GID INT NOT NULL AUTOINCREMENT,
Pic_IT VARCHAR(10) NOT NULL,
Pic_ES VARCHAR(10) NOT NULL,
Pic_DE VARCHAR(10) NOT NULL,
Pic_FR VARCHAR(10) NOT NULL,
Pic_EN VARCHAR(10) NOT NULL,
PRIMARY KEY(GID)
);
CREATE TABLE SubGroups (
SGID INT NOT NULL AUTOINCREMENT,
GID INT	NOT NULL,
Description VARCHAR(100) NOT NULL,
Pic VARCHAR(10)	NOT NULL,
PRIMARY KEY(SGID)
);
CREATE TABLE Products (
PID INT	NOT NULL AUTOINCREMENT,
SGID INT NOT NULL,
Item VARCHAR(10) NOT NULL,
Description VARCHAR(100),
Price VARCHAR(10),
Weight VARCHAR(10),
PRIMARY	KEY(PID)
);
Non badate ai tipi, li devo ancora definire per bene, questa è solo una
prova.
Ora, il punto è che ogni volta che
inserisco un prodotto devo inserire diverse volte lo stesso dato (GID,
SGID) e ogni volta che cambia l'organizzazione dei prodotti devo
ricordarmi di fare un'update su tutte le tabelle, il che mi sembra una
soluzione non ottimale e prona agli errori.
Sto valutando l'ipotesi di creare una unica tabella, anche se mi sembra
poco logico...
Vorrei sapere da voi come vi comportereste, tenendo conto dello
strumento.
TIA,
	Nicholas

 e in un sottogruppo:
Io farei un'unica tabella "gruppi", piu' o meno cosi'...
create table groups (
	group_id	int not null,
	supergroup	int not null,
	description	varchar(50) not null,
	... altra roba ...
)
Ergo: ogni gruppo puo' avere un "supergruppo" che punta alla stessa
tabella, quindi ogni gruppo puo' avere infiniti sottogruppi.
E la struttura e' gerarchica ed eventualmente ricorsiva.
Sui prodotti ti serve un solo ID di gruppo, spostare un pacco di
prodotti da un sotto gruppo ad un'altro e' solo cambiare un campo.
Davide

 : 

In effetti così è più sensato, però a mio avviso (cioè da uno che ha a
che fare con i database da meno di un anno, ma che però si impegna... :)
gruppi, sottogruppi e prodotti sono entità distinte...
Se il DBMS fosse stato un'altro la disposizione che avevo pensato
avrebbe avuto senso o sarebbe stata comunque errata ?
Ciao, grazie mille,
	Nicholas

 avrebbe avuto senso o sarebbe stata comunque errata ?
Non esistono strutture "errate", esistono strutture piu' o meno
ottimizzate e piu' o meno efficienti per quello che devi fare.
Per quanto riguardo il fatto di avere "entita'" definite in
differenti tabelle, dipende tutto da come gestisci la struttura
in seguito. La teoria dice che ogni signola entita dovrebbe essere
definita in una singola tabella, ma la pratica dice anche che a volte
e' meglio di no.
Davide

 : 

Ok, epperò ho dimenticato una specifica: un 'sottogruppo' può
appartenere a più 'supergruppi'. Non capisco come riuscire a rendere una
cosa del genere in modo minimamente logico. Non i prodotti, gli interi
sottogruppi...
TIA,
	Nicholas

sottogruppi...
Una tabella is_a:
	Oggetto		Gruppo
	12		25
	12		36
In questo caso l'oggetto 12 appartiene ai gruppi 25 e 36, e potrebbe
appartenervi in piu' di un modo, se aggiungessimo che
	25		36
(Questo genere di intrecci andrebbe ottimizzato via a parte, magari,
ogni tanto, percorrendo la tabella is_a).
Leonardo
-- 
the shadow of the dome of pleasure
floated midway on the waves,
where was heard the mingled measure
from the fountain and the caves.