Come gestire un gran numero di attributi su un entità??

[bertag]

Ciao a tutti,
ho realizzato un database che contiene un entità di nome attivita (rima involontaria), la tabella attivita deve descrivere varie tipologie di enti che variano da negozi, bar fino ad arrivare ad hotel, b&b ecc ecc. Come potete immaginare anche dal titolo questa entità è molto generica quindi necessito di un gran numero di attributi per poter descrivere una qualsiasi tipologia, parzialmente mi viene in aiuto l'entità categorie che mi identifica il tipo di attività che sto trattando. Ora mi trovo pero ad avere un entità di tipo "attivita" descritta da 24 attributi (comprensivo di chiavi esterne) molti dei quali di tipo TYNINT(1), quindi non molto esigenti in quanto a memoria, ma la domanda nasce spontanea.... quando arriva il momento di chiedersi se il numero di attributi è troppo grande e quindi prendere provvedimenti?? E se si quali possono essere i provvedimenti? Nuove entità, trasferimento di attributi sotto entità collegate da chiavi esterne??
Grazi a chi mi darà un aiuto.

[franzauker2.0]

Se non ci sono gravi problemi di interrogazioni di tipo LIKE, usualmente, si condificano mediante stringhe (in tempi andati mediante bit, ma ormai è desueto).
Esempio: alto, bello, scemo, sposato => alto;bello;scemo;sposato;

[bertag]

è un ottima idea ma il mio problema è che ad ogni campo come alto, bello, scemo, sposato è associata un'immagine che se il campo è 1 (true) visualizzo l'immagine altrimenti no (visione molto semplificata del problema) quindi quando un'interrogazione mi restituisce per alto ->1 bello->1 scemo->1 sposato->0 devo visualizzare nel lato client le tre immagini relative ai primi 3 campi e "nascondere" l'immagine relativa all'ultimo campo. Con implementazione a bit ho un risparmio di spazio e quindi velocità di recupero info e una gestione meno semplice della procedura, con campi di testo dovrei lavorare sulle stringhe restituite e impostare procedure di inserimento sicure e questo rende tutto più complicato e soggetto ad errori.

L'idea di base della mia domanda è se un DB contenente entità con molti attributi è da considerarsi mal progettato e se si quali accorgimenti adottare
Grazie della risposta

[franzauker2.0]

Originariamente inviato da bertag
è un ottima idea ma il mio problema è che ad ogni campo come alto, bello, scemo, sposato è associata un'immagine che se il campo è 1 (true) visualizzo l'immagine altrimenti no (visione molto semplificata del problema) quindi quando un'interrogazione mi restituisce per alto ->1 bello->1 scemo->1 sposato->0 devo visualizzare nel lato client le tre immagini relative ai primi 3 campi e "nascondere" l'immagine relativa all'ultimo campo. Con implementazione a bit ho un risparmio di spazio e quindi velocità di recupero info e una gestione meno semplice della procedura, con campi di testo dovrei lavorare sulle stringhe restituite e impostare procedure di inserimento sicure e questo rende tutto più complicato e soggetto ad errori.

Non ho capito un granchè, ma segnalo che puoi usare banalmente delle maschere in potenza di due da "AND-are" con campi interi, se vuoi "impacchettare" i dati.
In generale, però, problemi di spazio non ci son più per i database (da un bel pezzo), in quasi ogni circostanza.

L'idea di base della mia domanda è se un DB contenente entità con molti attributi è da considerarsi mal progettato e se si quali accorgimenti adottare
Grazie della risposta

La risposta è: un db che funziona bene è ben progettato, che contenga pochi o tanti attributi è irrilevante, giacchè dipende da cosa si vuol modellare.

Per la buona progettazione, entrano in gioco argomenti del tutto diversi, come
- prestazioni e limitazione dei join
- comodità di utilizzo da parte del programma
- comodità di manutenzione (aggiornamenti, backup, restore)
- (verso gli ultimi posti) spazio occupato

Nel mondo "reale" tabelle con fino a un centinaio di campi sono ritenute del tutto normali.
Oltre iniziano a diventare scomode da gestire.
Esistono limitazioni varie, tipicamente sulla dimensione complessiva di una riga con riferimento alla suddivisione in pagine della memorizzazione dei dati a livello fisico dal parte dell'RDBMS, ma come detto sopra se arrivi a quei livelli significa che hai problemi grandi, tali per cui serve un progettista abituato a maneggiarli.

Se sono troppo saccente segnalalo pure, tanto... pazienza

[bertag]

Non sei per niente seccante anzi, nonostante la confusione della mia prima risposta (lo ammetto forse non sono stato poi così chiaro ma spiegare la logica che si ha in testa ad una persona non è sempre facile ) hai saputo rispondere alla mia domanda... 24 attributi non sono poi così tanti (se non ho capito male)! Non essendo abituato a DB progettati per lavoro ma solo a scopo didattico anche arrivare a 10 attributi mi sembrava forse un po' esagerare , ma parlare con qualcuno che ha decisamente più di esperienza in casi pratici aiuta sempre quindi grazie ancora per la risposta!!!

[franzauker2.0]

Originariamente inviato da bertag
Non sei per niente seccante anzi, nonostante la confusione della mia prima risposta (lo ammetto forse non sono stato poi così chiaro ma spiegare la logica che si ha in testa ad una persona non è sempre facile ) hai saputo rispondere alla mia domanda... 24 attributi non sono poi così tanti (se non ho capito male)! Non essendo abituato a DB progettati per lavoro ma solo a scopo didattico anche arrivare a 10 attributi mi sembrava forse un po' esagerare , ma parlare con qualcuno che ha decisamente più di esperienza in casi pratici aiuta sempre quindi grazie ancora per la risposta!!!

Considera che un DB complessivamente di qualche gigabyte è tranquillamente alla portata di un PC da discount (nel senso da 500 euro o poco più) e qualche gigabyte significa, ad esempio un milione di righe complessivamente per 1K ogni record (sìsì c'è l'overhead, lo space table nel caso di innodb, l'inevitabile indice primario sempre di innodb blablabla).
E un milione di righe non sono poi così poche, sono ad esempio tutti i post di un forum con migliaia di utenti nell'arco di un decennio.

E parliamo sempre di una macchina da discount

[bertag]

certamente, la gestione del DB da parte di un server non arriva a preoccuparmi altrimenti cambierei servizio di hosting se per qualche milione di righe inizia a faticare, ma questo va al di fuori della discussione, in fin dei conti un entità con molti attributi sono un problema più per il programmatore che dovrà gestirle piuttosto che di chi progetta il DB, se poi si tratta della stessa persona qualche dubbio è lecito....

[franzauker2.0]

Originariamente inviato da bertag
in fin dei conti un entità con molti attributi sono un problema più per il programmatore che dovrà gestirle

Direi in generale il contrario, più "roba" c'è nella singola tabella, più normalmente è facile (e veloce) manipolarla da programma.

Ma, in definitiva, cosa ti "turba"? (o meglio perchè secondo te potresti esserlo?)

[bertag]

in fin dei conti non mi turba niente... le mie risposte le ho ottenute ! Aumentando il numero di tabelle su aumentano la difficoltà sulle query da eseguire per recuperare i dati effettivamente....

[franzauker2.0]

Originariamente inviato da bertag
in fin dei conti non mi turba niente... le mie risposte le ho ottenute ! Aumentando il numero di tabelle su aumentano la difficoltà sulle query da eseguire per recuperare i dati effettivamente....

bhè cercavo maieuticamente di farti ragionare sul "perchè" qualcosa potrebbe essere bene, o male.
Vedo che, con l'ultima osservazione, in realtà... sapevi già la risposta