performance tabella.. quale soluzione

[dottwatson]

buonasera a tutti

ho questo problema non indifferente...

ho 15000 articoli e 350 clienti.

ogni cliente ha un suo prezzo per il determinato articolo e devo definirlo appunto in questa tabella.

le strade possibili sono 2 (è una tabella che ogni notte viene ELIMINATA e ricreata):


dati di esempio:
codice articolo=S2345
codice cliente=00032


SOLUZIONE 1
creo la tabella con tre colonne

cod_art
cod_cli
prezzo

in questo caso avrei 5.250.000 righe e 3 colonne

e la query
select prezzo from tabella where cod_art='S2345' AND cod_cli=00032

====================================
2)

creo una tabella con 351 colonne

cod_art
00032
00033
00034
...
00385

in questo caso avrei 15.000 righe e 351 colonne

quindi la query
select 00032 from tabella where cod_art='S2345'
=====================================


quale delle 2 devo reputare piu performante?

su questa tabella vengono fatti anche gli ordinamenti per prezzo ....

[webus]

la situazione ha un che di onirico
La soluzione più logica sarebbe che il cliente cambi mestiere, ma non era nelle opzioni...

Comunque direi la prima: 15000 x 350 righe, non solo per ragioni di performance, ma pure per semplicità di mantenimento. Difatti è ipotizzabile, oltre che auspicabile, che i clienti cambino di numero e ciò renderebbe sempre più complessa la gestione della struttura stessa della tabella.

La naturale chiave primaria sarebbero le due chiavi cod_art e cod_cli.

[dottwatson]

quindi 15 milioni di righe...

[webus]

Originariamente inviato da dottwatson
quindi 15 milioni di righe...

beh no, 15.000 x 350 = 5.250.000 come hai scritto sopra.

Ah, sopra dicevo della chiave primaria composta, solo che trovo importante fissare come chiave sinistra il codice cliente invece che cod_art come avevo indicato. Il codice cliente ha un numero di ricorrenze decisamente inferiore, per cui è in grado di isolare prima la sequenza di record interessata.
Comunque dovrai fare delle prove sul campo per vedere come impostare la query migliore.

Un altro fattore che sconsiglia la soluzione 2 è che ti sarebbe quasi impossibile crearci degli indici (su 350 colonne!) dato che oltre al peso in sé, rallenterebbero a dismisura l'inserimento/aggiornamento giornaliero.
E poi viola il principio di normalizzazione nella First Normal Form (1NF)

[dottwatson]

Originariamente inviato da webus
beh no, 15.000 x 350 = 5.250.000 come hai scritto sopra.

Ah, sopra dicevo della chiave primaria composta, solo che trovo importante fissare come chiave sinistra il codice cliente invece che cod_art come avevo indicato. Il codice cliente ha un numero di ricorrenze decisamente inferiore, per cui è in grado di isolare prima la sequenza di record interessata.
Comunque dovrai fare delle prove sul campo per vedere come impostare la query migliore.

Un altro fattore che sconsiglia la soluzione 2 è che ti sarebbe quasi impossibile crearci degli indici (su 350 colonne!) dato che oltre al peso in sé, rallenterebbero a dismisura l'inserimento/aggiornamento giornaliero.
E poi viola il principio di normalizzazione nella First Normal Form (1NF)

il problema degli indici lo avevo individuato anche io appena dopo il post, cerco comunque alternative e suggerimenti in merito .. magari una terza opzione si trova! attualmente ho php 4
e mysql 4, ho provato sia le tabelle temporanee (che mi servono lungo tutta l anavigazione) e le tabelle istantanee, ovvero tabelle create sull' id di sessione che si occupavano proprio di fare la raccolta dati 'pappa pronta' per la navigazione. Routins di eliminazione e controlli vari...

Sinceramente penso sia una mezza porcatina mettere così sotto stress il motore di mysql, ma mi serve assolutamente il risultato. ogni creazione di tabella mi prendeva dai 40 ai 53 secondi di creazione, quindi ho pensato di agganciarmi alla sync notturna e generare 'il tabellone'




15 milioni mi sono confuso se sbaglio quello allora ho sbagliato mestiere lol

mi dici invece qualcosa riguardo alle primarie composte? anche link, documentazione in generale

grassie

[webus]

Originariamente inviato da dottwatson
Sinceramente penso sia una mezza porcatina mettere così sotto stress il motore di mysql, ma mi serve assolutamente il risultato. ogni creazione di tabella mi prendeva dai 40 ai 53 secondi di creazione, quindi ho pensato di agganciarmi alla sync notturna e generare 'il tabellone'

la cosa illogica a mio avviso è quella di assegnare un prezzo ad ogni cliente per ogni articolo. Non conosco ovviamente la situazione, ma non vogli pensare a quanta gente sia dedicata a questa "personalizzazione" dei prezzi. Mah.
Comunque anche la cancellazione/creazione della tabella è un punto evitabile. Immagino che non si aggiornino tutti gli oltre 5milioni di prezzi ogni giorno, probabilmente un REPLACE INTO basterebbe a soddisfare un aggiornamento periodico.

mi dici invece qualcosa riguardo alle primarie composte? anche link, documentazione in generale

Al momento non ho link da segnalarti, poi vedo se ne trovo, per ora posso dirti che non li puoi creare con CREATE INDEX, ma solo con CREATE/ALTER TABLE:

CREATE TABLE miaTabella (
    ...
    PRIMARY KEY  (cliente_cod,art_cod)
) 

un altro vantaggio di questo tipo di indecie è che lo puoi usare anche solo per la prima colonna sinistra (in questo caso cliente-cod) mentre per una ricerca indidizzata sulla colonna destra dovrai creare un nuovo indice ad-hoc.

Comunque non mi farei impressionare da una tabella di 5 milioni di record. Se bene indicizzata ti garantisce comunque discrete performance.


[edit]
una ricerca in google per "mysql tuning multiple-column index" ritorna parecchi risultati.

[Linus80]

innanzitutto inizio con questo messaggio la mia attività su questo forum... lavoro da poco meno di un annetto con php e mysql e spero di essere degno di entrare in questa simpatica famiglia

che dire... meglio la soluzione (1) con le sue 5 milioni e passa di righe. La forza dei DB sta nella loro relazionalità, per cui perchè privarti della possibilità di avere un giorno 10 clienti in più?

Va bene come esordio?