Newsgroup: it.comp.software.database
Titolo: come organizzare record di dati

Non sono uno sviluppatore professionista e vorrei un consiglio su come
organizzare i dati di una tabella Access gestita da pagine web.
 
Schematizzo la situazione:
 
mettiamo di aver bisogno di salvare dei dati in una tabella e associati a 
utenti contenuti in altra.
Ogni "salvata" per lo stesso utente può contenere tipi diversi e quantità 
diversa di dati, ma tutti
afferenti a quella tabella, quindi impossibile organizzare un record con dei 
campi determinati.
 
La mia idea è quella di salvare tutti i dati del record in un'unica stringa 
con un separatore marker
che poi servirà a splittare la stringa al suo utilizzo.
Ad esempio, volendo salvare i due record:
1) Identificatore: 1, Tipo: bianco, Grandezza: 2, Data: 1/2/2012
2) Identificatore: 2, Lunghezza: 100, Largezza: 10, TipoA: 2, TipoB: 3, 
TipoC: 6
 
Salverei le stringhe così:
1) 1§bianco§2§1/2/2012
2) 2§100§10§2§3§6
 
Secondo voi è una buona idea?
Esiste un qualche trucco standard per operare con dati variabili?
 
grazie per l'aiuto
 
 
-- 
ciao!
 
...nixs.................................................................
nixs.lucchetto.@lagirandola.it
 
togli la ".SERRATURA." per scrivermi
........................................................................
L'uomo non smette di giocare perché invecchia,
ma invecchia perché smette di giocare.
(George Bernard Shaw) 
 


Sei completamente fuori strada.
1) cosa vuol dire "mettiamo di aver bisogno di salvare dei dati in una 
tabella"? Che tipo di dadi fanno inseriti in questa tabella?
2) "utenti contenuti in altra", suppongo sia una tabella di nominativi.
In che rapporto stanno fra loro le due tabbelle? 1 a molti? o molti a 
molti?
In entrambi i casi devi inserire un IDrecord (chiave univoca) nel 
socondo devi fare una tabella intemedio con almeno 3 campo IDtabellaMM, 
IDtabella1, IDtabella2.
3) "La mia idea è quella di salvare tutti i dati" NO. Esistono in campi 
che sono i "componenti dei record" e vanno utilizzati per quanto possibile.
Mettere tutto in campo da splittare alla rilettura rende molto 
difficoltose le query di selezione per filtrare i dati che interessano e 
rallentano la fuoruscita dei dati.
Leonardo
 
 

 Esiste un qualche trucco standard per operare con dati variabili?
 
Non esistono trucchi ma un approccio razionale.
 
Senza conoscere il problema specifico posso fare solo un esempio:
gestisco un sito di acquisti online e vendiamo di tutto dal posacenere
alla centrale nucleare, ok.
 
Magari potresti pensare, semplifico, che un utente (tab utenti) fa degli
ordini (tab ordini) ognuno con determinati articoli (tab articoli) e per
ogni articolo ci sono delle caratteristiche (tab caratteristiche) che
devono essere specificate.
 
 
 
-- 
In God we trust. All others must bring data
W. E. Deming

fuoruscita dei dati.
 
Difficoltose le query??? E' il caso più semplice:
"prendi tutti i record di questo test"
Poi il campo che contiene il quesito vero e proprio viene decodificato dalla
funzione che ricostruisce tutto nella pagina.


 richiamare.
 
Mi richiamero` gli strali degli altri nel ng, ma secondo me hai scelto 
l'opzione giusta, solo che io la farei in modo diverso.
 
Visto che non devi fare query interrogando questi campi, li puoi 
codificare come vuoi. Io farei semplicemente un array o un oggetto in PHP 
e poi userei serialize() (e unserialize() in lettura).
Cosi` non ti devi nemmeno scrivere la funzione di encoding e decoding, e 
soprattutto, se usi l'autoloader per le classi e segui la PSR-0 (la 
struttura gerarchica standard di PEAR per le classi), l'unserialize ti 
reistanzia anche automaticamente l'oggetto al decoding.
 
Serialize aggiunge un po' di overhead, ma credo che gzippare il campo 
prima di metterlo in un blob nel DB sia un po' eccessivo. :D
 
Bye.

e poi userei serialize() (e unserialize() in lettura).
 
Mi convinco sempre più della potenza di PHP e per questo ho appena 
acquistato
un libro per studiarlo, ma quello che hai detto per me, per ora, è peggio
che arabo.
L'applicativo lo sto scrivendo in ASP classico, VBscript e DB Access, girerà
su server della rete locale della scuola e, se avrà successo e quando avrò
imparato PHP, lo tradurrò in PHP sul web.
Ma per ora si lavora con DB Access, con tutte le sue limitazioni ma con 
questo.



Secondo me il database, oltre ed essere impostato in modo logico (e può 
essere impostato in modi diversi) dovresti anche tener conto della 
estrazione dei dati. Cioè del modo in cui vuoi estrarli raggruppandoli 
fra loro.
Comunque, da quello che ho capito hai un elenco di utenti ed un elenco 
di test da far eseguire.
Quindi ogni utente può fare più test ed ogni singolo test può essere 
fatto da utenti diversi.
Ti serve una tabella utenti con IDu primario, una tabella test con IDt 
ed una tabella intermedia con tre campi  ID  - IDu – Idt per collegare 
le 2 tabelle principale.
Tabella utenti; non ci sono problemi, oltre a IDu, altri campi con nome 
cognome eccetera.
Tabella Quiz: Da quello che ho capito le stessa/e domande possono 
trovarsi in quiz diversi, per questa ragione io farei una tabella con 
tutte le domande e poi con una query mostrerei all’utente solo le 
domande necessarie per ogni tipo di quiz.
  Da diverso tempo ho abbandonato Access in favore di PHP/MySQL e posso 
dirti che se i campi testo sono warchar non c’è spreco di spazio se 
rimangono vuoti.
Sempre facendo una unica tabella per i test, hai la possibilità di 
estrarre i dati anche considerando campi che non appartengono allo 
stesso test permettendoti di valutare i risultati (dei test) nel modo 
che riterrai più opportuno.
Nel post precedente, per  query difficoltose intendevo dire che se fai 
un unico campo divisso internamente a questo modo 1§bianco§2§1/2/2012 
puoi ritrovarti ed estrarre campi che non ti interessano perché se 
scrivi like *2* (access) o like %2% MySQL puoi estrarre 
1§bianco§2§1/2/2012   ma anche 1§bianco§7§1/2/2012 e 1§bianco§2§1/3/2011 
il che non mi pare molto omogeneo.
Se pensi di passare a PHP Mysql fallo subito, ti eviterà di riscrivere e 
ricontrollare il fatto con Access.
Saluti
Leonardo
 

 [...]
 
 
Ciao  Manlio

omogeneo.
 
Assolutamente, nessuna query NEL campo, solo l'INTERO campo o NIENTE.
Non mi serve estrarre dati dalla stringa, devo solo estrarre tutti i record 
che appartengono
allo stesso test del dato utente, a prescindere di cosa ci sia dentro il 
campo con la
stringa codificata.
 
Per quanto riguarda PHP... sto studiando :-)))


 gestione delle stringhe codificate da salvare e da richiamare.
 
Per quale motivo 24 funzioni di codice rappresentano un risparmio
rispetto a 12 tabelle? Hanno messo una tassa sulle tabelle per
salvare la Grecia?
L'unico risultato e` che si sta spostando la complessita` dal
database al codice, dove in aggiunta, ogni bug si traduce
direttamente in dati persi, e dove -sorpresa- la struttura del db
esiste ancora, solo che e` camuffata perche' e` fusa col codice,
ed ora e` piu` fragile che mai.
 
Infine visto che il tutto si sviluppera` in ambiente scolastico,
considera anche che in alcune scuole superiori gia' si insegnano
le forme normali: se qualcuno vede lo schema, il db sollevera'
non pochi commenti dato che non raggiunge nemmeno la prima
forma normale...
 
 
 


contento te.
Leonardo
 

salvare la Grecia?
 
Ok, allora, mettiamo che le 12 tabelle abbiano nome T1... T12, che
ogni tabella è diversa da un'altra (alcune contengono 2-3 campi, altre fino
a 35 campi).
Fammi questa query:
"Estrai le domande con le relative risposte di tutti i quesiti dalle 12 
tabelle appartenenti al test ID = 333"
 
La mia sarebbe:
SELECT Quesito FROM Quesiti WHERE IDtest = 333 ORDER BY IDquesito ASC"
Vediamo la tua:
....


 ASC"
 
E' sbagliata: per quello che posso vedere hai recuperato i quesiti,
ma mancano le relative risposte. E cosa molto piu` importante,
perche' e` il punto focale del discorso, hai recuperato tutta
la stringa senza passarla alla decodifica delle funzioni PHP
di cui parlavi (due per ciascun quesito).
 
Ammesso e non concesso che un equivalente design normalizzato
debba implicare 12 tabelle T1...T12, un equivalente design non
normalizzato consterebbe in 1 tabella denormalizzata piu' 12
funzioni FR1...FR12 per la lettura piu' 12 funzioni FW1...FW12
per la scrittura IL CHE SIGNIFICA CHE SIAMO GIA' A PIU' DEL
DOPPIO del codice da scrivere.
 
Pertanto ci sarebbe da fare una prima query di recupero dei Quesiti,
una decodifica della stringa Quesiti, una riscrittura del campo
cosi' espanso in una struttura temporanea manipolabile dal
codice PHP (ricordarsi che ciascun quesito ha un formato
differente, quindi questa struttura temporanea deve essere a sua
volta differenziata), poi andrebbe in qualche modo fatto
un Join con la tabella Risposte.
 
Ora, se per sventura, i dati cosi' ottenuti devono essere oggetto
di un report di Access, gli stessi devono essere DI NUOVO
reimmessi all'interno del database, diciamo in una tabella
temporanea, e solo dopo puo' essere stampato il report.
 
Ora tu credi che questo giro astruso sia piu' veloce di una
equivalente query lato server? Credi davvero di riuscire a
costruire in un linguaggio come PHP qualcosa di piu' efficiente
di un motore di database?
 
 

equivalente query lato server?
 
E fammela 'sta query, la voglio vedere... per curiosità :-)))


 possibile... non mi hai risposto.
 
http://www.dbdebunk.com/page/page/2849682.htm
 
 
 

di tempo, da entrambe le parti...
 
quindi stai dicendo che siccome mostro ignoranza in tale situazione, mi 
scarichi?
 
Scusa per averti fatto perdere del tempo...



Ho seguito con interesse i vostri post, non mostri ignoranza, nessuno sa 
mai tutto, mostri arroganza e supponenza.
Leonardo

 
 
No ti sta dicendo che per andare dove vorresti, la cosa migliore sarebbe
usare l'auto mentre tu dici che è meglio usare il tandem e solo al
20esimo post ci spieghi che non hai la patente.
Ecco quella era la cosa da dire subito.


mai tutto, mostri arroganza e supponenza.
 
non so da cosa lo deduci, ma non fa niente, con arroganza saluto, ringrazio, 
mi scuso e non disturbo più...


20esimo post ci spieghi che non hai la patente.
 
ok, ok, diciamo che ho la patente A, la C non mi è mai servita :-))
 
diciamo che riesco a gestire join e union su 2-3 tabelle,
ma con 12 proprio non ne ho la più pallida idea.
Ma poi, mi ripeto, non è uno stress eccessivo per il motore di Access una
botta del genere?
