consiglio su supporto di memorizzazione

[Kelly]

Salve,

Avrei impellente necessità di farmi consigliare il modo giusto per la memorizzazione dei dati da un sito web.

Supponiamo che io abbia 2000 clienti, ognuno dei quali ha necessità di fare periodicamente un ordine con tanti articoli, un singolo ordine può anche arrivare a 300 righe ....
Il modo migliore per memorizzare dati è sicuramente il database, nel mio caso specifico si tratta di MySql,
pensavo di creare una tabellla per ciascun cliente a runtime da codice php, ed utilizzare sempre la stessa tabella, che posso cancellare quando evado l'ordine o modificare.

Quindi avrei un unico database e x tabelle, chiaro che se ho 2000 clienti, avrei 2000 tabelle.
A questo punto quali sono le cose negative alle quali potrei andare incontro?

E' consigliabile un database anche in questo caso?


grazie mille!

 

[borgo italia]

ciao
ti sposto in mysql
comunque cosa intendi per supporto? cd, chiavette...?
o come organizzare il db?
comunque così a prima vista l'idea di 2000 tabelle è da scartare

 

[Kelly]

ciao grazie


Per supporto di memorizzazione intendo il database ad esempio...
e come organizzarlo secondo le mie necessità, spiegate nel post precedente.

grazie

ciao
ti sposto in mysql
comunque cosa intendi per supporto? cd, chiavette...?
o come organizzare il db?
comunque così a prima vista l'idea di 2000 tabelle è da scartare

 

[marino51]

non hai indicato la perodicità dell'ordine,
se l'ordine fosse settimanale avresti 30 milioni di record/anno (50 settimane)
che si dimezzano x ordini quindicinali ed altrettanto per ordini mensili
quindi da 30 a 7,5 milioni di record/anno
non hai indicato il tempo di completamento dell'ordine, assumo ordini serviti velocemente
quindi che esauriscono la loro vita in breve tempo (qualche giorno)

credo che l'importanza del database, suggerisca di avere un'attenzione per soluzioni di backup efficienti
oltre che attenzione al tempo di risposta ed alla ricerca dei dati

consideriamo anche che il "motore" del database è già di suo ottimizzato per la ricerca delle informazioni

condivido poco l'organizzazione delle tabelle per cliente, ma propendo più per,
la tabella degli ordini attivi e le tabelle degli ordini archiviati ( + ddt + fatture + note di variazione )
tutte con adeguata indicizzazione (magari non basata sugli "id" automatici)

si potrebbero creare delle tabelle settimanali (52/anno), quindicinali o mensili in cui spostare gli ordini esauriti
(lo spostamento fatto con query secche, magari con commit/rollback, non con giri di php o altro linguaggio)

DELETE FROM tabella OUTPUT DELETED.* INTO archivio_201312 WHERE yearmonth=201312

delle view ben fatte, sulle tabelle nell'insieme, possono poi consentire la ricerca dei documenti con una "programmazione" semplice

infine le tabelle d'archivio, ormai statiche, possono generare dei file di "testo" da archiviare su supporti
che ne consentono la "durata" nel tempo (vedi aspetti civilistico/fiscali meglio soddisfatti da una buona base dati)

da ultimo prima di decidere, keep it simple !
ciao
Marino

 

[Kelly]

consiglio su supporto database

Ciao Marino

ti ringrazio per la risposta,
Il cliente può fare l'ordine ogni settimana, due al giorno , uno al mese, dipende da ciascun cliente!
Non ho necessità di suddividere ordini attivi o archiviati.
Ho bisogno di una tabella sulla quale memorizzare un ordine per volta,nel senso che
quando il cliente evade l'ordine, quindi lo invia per la preparazione della merce, io cancellerei la tabella, se invece non
lo evade , allora si ritroverebbe sempre quell'ordine che può modificare, e starebbe in piedi finchè non lo evade.
Ho pensato di creare una tabella per ogni cliente perchè se facessi un'unica tabella con tutti i record dei clienti penso che sarebbe peggio...oltretutto so che mysql con TRUNCATE ha la possibilità di cancellare la tabella e ricreare la struttura , evitando quindi il discorso della compattazione....che ne pensi....!

non hai indicato la perodicità dell'ordine,
se l'ordine fosse settimanale avresti 30 milioni di record/anno (50 settimane)
che si dimezzano x ordini quindicinali ed altrettanto per ordini mensili
quindi da 30 a 7,5 milioni di record/anno
non hai indicato il tempo di completamento dell'ordine, assumo ordini serviti velocemente
quindi che esauriscono la loro vita in breve tempo (qualche giorno)

credo che l'importanza del database, suggerisca di avere un'attenzione per soluzioni di backup efficienti
oltre che attenzione al tempo di risposta ed alla ricerca dei dati

consideriamo anche che il "motore" del database è già di suo ottimizzato per la ricerca delle informazioni

condivido poco l'organizzazione delle tabelle per cliente, ma propendo più per,
la tabella degli ordini attivi e le tabelle degli ordini archiviati ( + ddt + fatture + note di variazione )
tutte con adeguata indicizzazione (magari non basata sugli "id" automatici)

si potrebbero creare delle tabelle settimanali (52/anno), quindicinali o mensili in cui spostare gli ordini esauriti
(lo spostamento fatto con query secche, magari con commit/rollback, non con giri di php o altro linguaggio)

DELETE FROM tabella OUTPUT DELETED.* INTO archivio_201312 WHERE yearmonth=201312

delle view ben fatte, sulle tabelle nell'insieme, possono poi consentire la ricerca dei documenti con una "programmazione" semplice

infine le tabelle d'archivio, ormai statiche, possono generare dei file di "testo" da archiviare su supporti
che ne consentono la "durata" nel tempo (vedi aspetti civilistico/fiscali meglio soddisfatti da una buona base dati)

da ultimo prima di decidere, keep it simple !
ciao
Marino

 

[marino51]

parlando di "truncate", io capisco che puoi avere solo un ordine attivo per volta per cliente
e ad evasione avvenuta, di fatto cancelli l'ordine ricreando la tabella.
se il cliente vuole tenere più ordini perchè si è fatto un "prograqmma" o perchè così gli garba, truncate non funziona più ...

non conosco la struttura di mysql, ma se il database fosse organizzato con un unico file per i dati ed un secondo file
per gli indici, cade il tuo ragionamento di, "evitando quindi il discorso della compattazione", in questa situazione
cancellare l'ordine o ricreare la tabella è la stessa cosa

dal tuo scritto traspare che non ti interessa l' archiviazione,
se è veramente così, avrai un database snellissimo con, al massimo, 2000 ordini ... 600.000 righe (+/- nel caso peggiore),
ti conviene seguire i ragionamenti che stai facendo ?
con una buona indicizzazione, non dovresti vedere tempi di attesa
ciao
Marino

 

[Kelly]

grazie per la risposta.....
la prenderò in considerazione.
ciao

parlando di "truncate", io capisco che puoi avere solo un ordine attivo per volta per cliente
e ad evasione avvenuta, di fatto cancelli l'ordine ricreando la tabella.
se il cliente vuole tenere più ordini perchè si è fatto un "prograqmma" o perchè così gli garba, truncate non funziona più ...



non conosco la struttura di mysql, ma se il database fosse organizzato con un unico file per i dati ed un secondo file
per gli indici, cade il tuo ragionamento di, "evitando quindi il discorso della compattazione", in questa situazione
cancellare l'ordine o ricreare la tabella è la stessa cosa

dal tuo scritto traspare che non ti interessa l' archiviazione,
se è veramente così, avrai un database snellissimo con, al massimo, 2000 ordini ... 600.000 righe (+/- nel caso peggiore),
ti conviene seguire i ragionamenti che stai facendo ?
con una buona indicizzazione, non dovresti vedere tempi di attesa
ciao
Marino