Newsgroup: it.comp.appl.access
Titolo: consiglio per un'architettura complessa?

devo cominciare a progettare un database quantitativamente complesso.
si tratta di immagazzinare dati relativi all'accessibilita' di varie
strutture, pubbliche o meno, da parte di persone che hanno handicap di
vario genere.
il problema e' questo: 
- la tipologia delle strutture e' vastissima (moltissime entita');
- per ogni singola struttura possono esserci decine e decine di
caratteristiche assai eterogenee da registrare (moltissimi attributi).
se facessi la prima cosa che potrebbe venire in mente, farei n tabelle
per ognuna delle n strutture, poi in ogni tabella farei m campi per
ognuna delle m caratteristiche da registrare.
alcune caratteristiche possono essere comuni (porte automatiche,
presenza di scalini...), ma ogni struttura puo' anche averne di
peculiari.
il problema e' che sono pressoche' certo di superare gli scogli delle
255 tabelle, e, per alcune di queste, dei 255 campi.
ne' posso mettermi a riprogettare il sistema di rilevazione che su
questo database dovrebbe appoggiarsi perche' e' il risultato di uno
studio specialistico di cui non sono competente, e la materia e'
intrinsecamente complessa.
una cosa a cui avevo pensato era:
- tabella strutture,
- tabella caratteristiche,
- tabella di join strutture_caratteristiche.
senonche' le caratteristiche sono, come dicevo, del tutto eterogenee:
possono andare dall'altezza di un bancone da terra (tipo dati long)
alla presenza o meno di segnalazione braille e di che tipo (stringa)
alla presena o meno di menu per diabetici (stringa), alla presenza o
meno di un'attrezzatura particolare (si'/no) ecc. ecc.
avevo quindi pensato che la tabella strutture_caratteristiche potesse
questo tracciato:
id_struttura, id_caratteristica, tipo_dati e poi un campo per ognuno
dei tipi dato.  a seconda del tipo dati necessario avrei riempito il
campo apposito.  ma mi sembra una gran porcata...
altro problema: orari di apertura, lingue parlate...
prendiamo il piu' semplice, le lingue parlate dal personale di una
certa struttura.  uno potrebbe mettere un flag per ognuna delle lingue
piu' comuni: inglese, francese, tedesco, spagnolo...  ma perche' non
olandese, o portoghese o swahili?  allora che faccio, metto un'altra
tabella di lingue parlate e la relaziono alla tabella strutture?
l'orario di apertura.  uno potrebbe mettere i campi orario_apertura e
orario_chiusura. si' vabbe', e gli intervalli del pranzo?  e la
chiusura settimanale?  e gli orari particolari stagionali?  che
faccio, metto un'altra tabella dove per ognuno dei 365 giorni
dell'anno metto gli n orari di apertura, chiusura, eventuale
riapertura, eventuale richiusura?
per quello che riguarda la quantita' di tabelle e campi, mi e' venuto
in mente, mentre scrivevo, che per ogni tabella_struttura potrei
mettere solo i campi peculiari e poi fare una tabella di campi comuni
a cui joinare.  ma sempre tremila tabelle struttura mi troverei a
gestire...
altri consigli, idee, suggerimenti?
-----------------------------------
Per favore, accodate due zeri al mio stipendio.  E' per renderlo Y2K-compliant.
-----------------------------------
togliete NOSPAM per rispondermi.
-----------------------------------
il sito comune di it.comp.database.access:
http://members.xoom.it/it_db_access

altri consigli, idee, suggerimenti?
Assumere un consulente per l'analisi dei requisiti?
Eh eh eh
Antonio
--
**************************
E' natale e siamo tutti piů buoni
Figuriamoci se era pasqua
**************************

Assumere un consulente per l'analisi dei requisiti?
Ehehe, stavo per offrire la mia consulenza!:-))
Saluti.
Luciano

altri consigli, idee, suggerimenti?
Togliere i  due zeri al tuo stipendio
Gabriele


T'hanno già legnato gli altri perciò mi posso limitare ad un bel:
eh eh eh....
Comunque Buon Natale!
Bye, Ste

 vario genere.
Scherzi a parte forse ti sei lasciato prendere alla sprovvista dalla
richiesta imponente del tuo cliente. Non vorrei fare la figura di quello che
scpre l'acqua calda, ma forse una strada praticabile potrebbe essere la
seguente:
Fai una tabella e la organizzi così:
TabellaTipologia (Possibili tipologie)
idTipologia(contatore) idEdificio Qualità    Valore
E un'altra così:
TabellaCaratteristiche (possibili caratteristiche di ogni singola tipologia)
idCaratteristica(contatore) idTipologia(numerico) Particolare Valore Note
poi le leghi per idTipologie con relazione 1 a molti, e lo stesso fai con
idEdificio per la tabella edifici.
A questo punto hai, per ogni edificio, una o più Tipologie, e per ogni
tipologia una o più caratteristiche.
Questo, chiaramente, è solo uno spunto; ma forse ho capito male io e bene
gli altri interpretando il tuo post più come uno scherzo che come una reale
domanda.
Ciao e auguri, Sib

>T'hanno già legnato gli altri perciò mi posso limitare ad un bel:
legnato... e' che non gli viene in mente nient'altro perche' sono
scrausi.


Togliere i  due zeri al tuo stipendio
intanto aggiungiamoli, poi vediamo.


domanda.
no no, e' proprio vero.  come ti dicevo, non e' affatto complesso, e'
solo un problema quantitativo.


 solo un problema quantitativo.
Lo spunto che ho suggerito è inadatto? Considerando che in quel modo
risolvi, forse, il problema della quantità di campi, quali sono, se ho
sbagliato, i limiti della mia idea?
Ciao, Sib


Mi sa proprio che ti dovrai gestire un po' di tabelle per le strutture,
chiaramente dividendole per tipologie (tab.strutt.sanitarie,
tab.strutt.ristorazione, tab.strutt.private, ecc.), poi un bel pacco di
tabelle tipologie (tab.caratteristiche accessib.interne,
tab.caratteristiche accessib.esterne, tab.menu.pranzi, tab.orari,
tab.chiusure, ecc, ecc) e un altro mazzo di tab relazioni.....
.....ma lo devi proprio fare 'sto lavoro pachidermico ?
Ciao e auguroni
Yan

.....ma lo devi proprio fare 'sto lavoro pachidermico ?
be', e' la classica opera buona, ma stavolta nei due $en$i, ovvero e'
moooOOOooolto buona anche per me... ;-)
come ti dicevo, non e' complesso qualitativamente, mal che vada butto
giu' ste 30mila tabelle con sti 40mila campi e buonanotte, ma visto
che due soldi ce li prendo volevo fare qualcosa di piu' carino.
il problema e' che non esiste uno schema definito per modellare
l'accessibilita' di una generica struttura nei confronti dei portatori
di handicap.  il modello che io dovrei convertire in database e'
comunque il risultato dello studio di gente molto in gamba, e se il db
di supporto che io devo fare (che servira' per una prova sperimentale
sul campo di rilevamento) sara' funzionale, anche la diffusione di
questo modello ne avra' giovamento.


sbagliato, i limiti della mia idea?
la tua idea andava bene e piu' o meno era la stessa cosa che pensavo
di fare.
il fatto e' che ogni tipologia puo' avere un tipo dati diverso, quando
stringa, quando intera, quando precisione doppia, quando booleana,
quando data/ora...
potrei anche predisporre un campo testo, poi un campo che specifica il
tipo dati desiderato e imbastire al volo una conversione verso il tipo
dati adatto, il problema e' che poi ci dovranno pacioccare degli
inesperti, per cui magari ti immettono qualcosa che non e' ben
convertibile e ci sono casini.  allora uno dovrebbe predisporre una
immissione guidata o un controllo sui dati immessi ed e' una rottura
di balle per me e per loro.
l'altra cosa che avevo pensato di fare era, nella tabella
caratteristiche che dicevi anche tu, di predisporre un campo per ogni
tipo dato e a seconda del tipo caratteristica riempire solo quello.
-----------------------------------
ATTENZIONE: il ng it.comp.database.access cambia nome e diventa it.comp.appl.access
linkatelo!


solo un problema quantitativo.
Premesso quanto sopra: ho riflettuto un bel po' sul problema da te esposto,
la conclusione a cui sono giunto e' che anche io imposterei il db su tre
tabelle, una per le strutture, una per le possibili caratteistiche, ed una
di join tra le prime due in cui raccogliere i dati per ciascuna
caratteristica, ed è questa una soluzione del resto che ho già adottato in
casi complessi di archiviazione dati anche se con meno attributi in gioco.
L'unica cosa che mi sento di suggerire è pretendi un  po' di iniziativa in
più da parte dell'utente, cioe' pretendi una maggiore flessibilita'
nell'utilizzo dell'archivio da parte dell'utente. Mi spiego meglio, quando
hai predisposto tre campi  per archiviare i dati (uno numerico,uno stringa e
uno booleano),  dovrà essere l'utente a stabilire come impiegarli per
archiviare gli attributi delle strutture, nel caso specifico che tu hai
fatto degli orari di apertura, l'utente puo' ad esempio scindere questa
caratteristica in altre minori: orario di apertura giorni lavorativi, orario
di apertura giorni festivi, orario di apertura autunnale ecc. ecc. per
ciascuna di queste caratteristiche potrà poi inserire il relativo valore.
Adattarsi per raggiungere lo scopo.
Saluti
Buon Natale
Gisco

devo cominciare a progettare un database quantitativamente complesso.
Trovati un db serio che gestisca record a lunghezza variabile e campi
di tipo variante (non chiedermi quale), poi ne riparliamo ;-)
--
Lorenzo Coronati
--
Quesito a risposta binaria SI/NO:
"Risponderai no a questa domanda?"
--