Newsgroup: it.comp.www.php
Titolo: Php+Mysql

Vorrei un vostro parere: dovendo realizzare un db contenente circa 500000
record da mettere su server avevo pensato di utilizzare mysql+php per
gestire il tutto, creando delle pagine php (da mettere su tutti i pc) che
vanno ad interfacciarsi al mio database posto su server.
Cosa ne pensate?E' la soluzione migliore??
Grazie a tutti!!!!!
Yuri
--------------------------------
Inviato via 
http://usenet.libero.it

Cosa ne pensate?E' la soluzione migliore??
Credo di si. :-)
Morde.
morde [at] programmer [.] net

 Cosa ne pensate?E' la soluzione migliore??
   Non mi e` chiara la frase "creando delle pagine php (da mettere su 
tutti i pc) che vanno ad interfacciarsi al mio database posto su 
server": le pagine PHP andranno su un web server (non necessariamente 
diverso dal server che esegue MySQL) e "tutti i PC" vi accederanno per 
mezzo del browser. Per lo meno, di solito si da cosi`; puo` darsi che tu 
abbia esigenze diverse, per cui ti chiedo qualche delucidazione in piu` 
nel merito.
-- 
Alla prossima,
Marco


Si hai ragione tu!!!! Ovviamente le pagine php sono sul server!!!Dal punto
di vista delle prestazioni cosa mi sapete dire???Ho la necessitą di
visualizzare al massimo 65000 record (nel mio caso sono articoli da inserire
in un preventivo).
Graziee!!
Alla prossima


 in un preventivo).
   Gli sviluppatori di MySQL sostengono, non senza qualche ragione, che 
il loro DBMS e` stato progettato proprio per garantire le massime 
prestazioni possibili a scapito di molte altre caratteristiche tipiche 
dei prodotti di quel genere (anche se si stanno adeguando anche in altri 
campi). Penso che dimensionando efficacemente il/i server in funzione 
delle connessioni previste, non ci saranno grossi problemi.
   Ovviamente, mi auguro che tu non abbia intenzione di "sparare" 
sessantacinquemila record in ogni response del web server... ;)
-- 
Alla prossima,
Marco


Beh dipende...nel caso peggiore sono 50000 record che devono popolare una
combobox e che devono essere visualizzati a piccoli gruppetti di 100
articoli. I 50000 record sono i risultato di una banale query di selezione.
Che ne pensi??
Grazie!


 100mbps...e purtroppo mi devo adeguare... :(
Leggi
http://www.mysql.com/information/presentations/presentation-oscon2000-20000719/index.html
(tutto su una riga se venisse tagliuzzato)
Per gli esperimenti puoi sempre creare un database pieno di voci random,
cosi' puoi calibrare la configurazione al massimo.
Io ho un DB random da 2 milioni di righe solo per stupire gli amici con le
prestazioni di MySql (neppure ottimizzato) rispetto ad Access.
Per curiosita': ma cos'e' che ha bisogno di 65000 voci in preventivo?
Uno shuttle?
ciao
Marco
-- 
bernama -ricciolino- libero -- it
OROSCOPO: non siate creduloni, o qualcuno tentera' di imbrogliarvi.
Mandatemi 50 euro per la consulenza astrologica, grazie.
M.B.
+- PHPRndSig 0.02 --------------------------------------------43/44-+

 Che ne pensi??
   Che sarebbe meglio utilizzare qualche forma di parzializzazione dei 
risultati (per esempio, la clausola limit nella select unitamente ad 
un'interessante gestione delle sessioni per propagare i parametri della 
limit stessa tra una transazione e l'altra). Per sapere quanti record a 
transazione puoi inviare (il problema non e` tanto di MySQL quanto di 
preparazione delle pagine e di traffico sulla rete) ti conviene fare 
qualche prova con recordset di dimensioni crescenti.
-- 
Alla prossima,
Marco

 Cosa ne pensate?E' la soluzione migliore??
In realtà credo che la tua domanda sia un po generica...oppure sono io che
non l'ho capita :)
Un db contente 500000 record non significa nulla. Il tuo db è formato da una
sola tabella contenente 500000 record coposta da 100 campi? E su questa
tabella ogni volta lanci una select leggi tutti e 100 i campi? Questo a
prescindere da quale db usi, è mortale. A parità di db e tecnologia usata
(php, asp, vb...) è già concettualemente sbagliato.
Se la tua preoccupazione è legata alle prestazioni di mysql, non posso dirti
come lavora con grossi carichi perhcè io lo uso a casa con tabella che se
superano 100 record è già tanto :) Un db ottimizzato, qualunque esso sia, è
già un buon punto di partenza. Normalizzare un db è la prima cosa da fare.
Se il tuo db è ben strutturato con tabelle di legame, indici e chiavi, inizi
a pensare alle prestazioni.
Inoltre, che carico stimi ci possa essere? Quanto sarà la mole di dati che
stimi vengano trattati? E' normale che se 10 utenti al giorno acceddono al
tuo db per leggere un nome, puoi anche organizzare il tutto anche su file
testuali :)) Se il carico è mooolto più grosso, allora la cosa cambia. La
tua macchina (il tuo server) ha abbastanza risorse (ram) da permettere al
tuo db di elaborare tranquillamente tutte le query e le richieste degli
utenti? Le stesse query che scrivi nel tuo codice, hai controllato che siano
performanti?
Quanti saranno gli utenti che contemporaneamente faranno richieste al tuo
db? 2 o 1000?
Che tipo di rete usi? Come sono collegati server e clients?
La scelta di una tecnologia è solo una minuscola parte di tutto lo studio
che dovresti fare tu. Scegliere php e non asp è una questione soggettiva più
che performante. E' il contorno a fare la differenza.
Spero di aver reso il concetto :))
Buon lavoro!!


(tutto su una riga se venisse tagliuzzato)
A proposito prova questo 
http://makeashorterlink.com/
In it.comp.lang.delphi lo usiamo molto per linkare google grooups (i suoi  post hanno link lunghissimi)
Ciao!


 combobox
50000 record che devono popolare una combobox in html
<option>valore</option>
sono (senza contare il valore)
17 byte * 50000=850000 byte = 0,81 MB
Zao

 ha scritto nel messaggio
news:81Z72Z3Z144Y10...@usenet.libero.it...


 Inviato via 
http://usenet.libero.it
ciao
Alesi_27

 ma spesso,almeno nella mia piccola esperienza, si procede al contrario).
Beh...il database è stupidissimo...si tratta di gestire i preventivi: 1
tabella articoli,1tab preventivi e una tab dettaglio_preventivi. Più di così
cosa devo spezzare? :)
Per quanto riguarda il popolamento della combo...se devo andare ad inserire
un articolo della Siemens che ha in listino 47000 articoli devo fare una
query che mi tira fuori dalla tabella articoli(con 500000 record) tutti gli
articoli della siemens e poi vado a popolare la combo...il discorso della
lentezza non sta nella visualizzazione, ma nell'esecuzione della query!
grazie!


 lentezza non sta nella visualizzazione, ma nell'esecuzione della query!
Il problema è sia di elaborazione della query quanto di impostazione del tuo
db. Quello che io farai è qualcosa del genere. Creo una tabella ANA_ARTICOLI
così composta:
[ANA_PRODUTTORI]
   CD_PRODUTTORE NUMBER(9) NOT NULL,
   DS_PRODUTTORE VARCHAR(2) 200 NULL,
   ....
   ..
   ...
PK: CD_PRODUTTORE
IDX: DS_PRODUTTORE
[L_PRODUTTORI_ARTICOLI]
   CD_PRODUTTORE NUMBER(9) NOT NULL,
   CD_ARTICOLO NUMBER(9) NOT NULL,
   ....
   ..
   ...
PK: CD_PRODUTTORE, CD_ARTICOLO
[ANA_ARTICOLI]
   CD_ARTICOLO NUMBER(9) NOT NULL,
   DS_ARTICOLO VARCHAR(2) 200 NULL,
   ....
   ..
   ...
PK: CD_ARTICOLO
IDX: DS_ARTICOLO
Per riempire la combo, useri una query tipo questa:
SELECT
  A.DS_ARTICOLO
FROM
  ANA_ARTICOLI A,
  L_PRODUTTORI_ARTICOLI L,
  ANA_PRODUTTORI P
WHERE P.CD_PRODUTTORE = X
AND L.CD_PRODUTTORE = P.CD_PRODUTTORE
AND A.CD_ARTICOLO = L.CD_ARTICOLO
In questo modo ho tante tabelline piccole divise in modo atomico. La join
non mi rallenta l'elaborazione della query perchè è fatta su chiavi primarie
che di per se sono già indici.
Così facendo evito di dover fare una select su una descrizione (una stringa)
che è già più lenta di una select fatta su una chiave/indice. Qualunque cosa
faccio la faccio su tabelle piccole indicizzate e non riporto le stesse
informazioni da altre parti.
Mettendo un indice sui rispettivi campi descrittivi delle tabbelle
anagrafiche, qualora volessi dare la possibilità di vedere tutti gli
articoli di un dato produttore, partendo dal nome, la ricerca sui nomi è
molto più veloce e con lo stesos procendimento di sopra mi muovo sulle
chiavi. Questo potrebbe essere utile se vuoi fare un campo di ricerca in cui
uno scrive liberamente il nome di un produttore e tu gli mostri tutto quello
che c'è di quel produttore ammesso che esista.
Oggi, hai imparato cosa significa normalizzare un db :)
Ci sono inoltre dei tools che ti aiutano nella ceazione/modellazione di un
db. Il migliore è sicuramente ERWin che ti permette di partire da un db
logico e crearne uno fisico. La stessa manutenzione del db fisico la puoi
fare smanettando sul modello logico.
Saluti...


In it.comp.lang.delphi lo usiamo molto per linkare google grooups (i suoi  post hanno link lunghissimi)
http://snurl.com
Ancora piu' corto :-)
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.

Ancora piu' corto :-)
Si.. e vero', pero' ha un sacco di features.... io mi trovo meglio 
con makeashorterlink: e' piu' pratico...semplice e immediato :-)


 wrote in message
news:81Z72Z3Z144Y1...@usenet.libero.it...

ok, allora io che mi son fatto un programma di gestione magazzino con oltre
50 tabelle?... mmm che pazzo sono..
PUOI SPEZZARE PIU' CHE PUOI:
fai delle tabelle del genere:
MAGAZZINO
ARTICOLI
ESISTENZE (dovrai pur controllare se l'articolo esiste o no)
FORNITORI
CLIENTI
TESTATA ORDINE
CORPO ORDINE
[MAGAZZINO]
    ID primaria
    descrizione
[ARTICOLI]
    ID primaria
    descrizione
    fID    ID fornitore - indice
    prezzo acquisto
    prezzo vendita    (se hai multimagazzino metti questi campi dentro la
tabella ESISTENZE)
    altri campi, crea sottotabelle il piu' possible per campo, e cerca di
inserire meno campi possibile di testo
[ESISTENZE]
    ID primaria
    aID    ID articolo - indice
    mID    ID magazzino - indice (per gestire il multimagazzino)
    esistenze    -    indice, cosi puoi sapere quali sono esistenti e quali
no
    ordinati
    venduti (da ordine)
se gestisci delle taglie puoi fare due cose, o tanti campi quante sono le
taglie massime, o un campo lungo NUMTAGLIE*10 dove 10 e' il massimo che puoi
raggiungere in quantita' (consider negativo e virgola) e metti gli spazi
bianchi dove non hai taglia e 0 dove non hai esistenza
[FORNITORI]
    ID primaria
    descrizione
    altre info (citta', telefono)
[CLIENTE]
    ID primaria
    descrizione
    altre info (citta', telefono, destinazione merce, eventuale sconto)
[TESTATA ORDINE]
    ID primaria
    fID    ID fornitore    indice
    cID    ID cliente    indice
    descrizione
    altre info (esempio sconti o altro)
[CORPO ORDINE]
    ID primaria
    oID    ID ordine    indice
    aID    ID articolo    indice
    quantita' ordinata
    quantita' arrivata
    prezzo acquisto    (per eventuali statistiche)
    prezzo vendita    (solo se puo' variare)
    sconto
    altre info
per il resto..., non ti faccio l'analisi, ma spero che tu abbia capito.. da
tre tabelle che avevi detto, te ne ho tirate fuori 7.. gli indici forse son
da rivedere secondo i tipi di query che fai sul DB, o i tipi di info che ti
servono.. se vuoi una dritta, fai in modo che la pagina sia divisa ALMENO in
due frames, le prima dove l'utente scrive almeno le iniziali del prodotto
che sceglie invia, la seconda si aggiorna con la lista dei prodotti che
hanno quella stringa dentro il testo (in questo caso metti descrizione come
indice).. nsomma, vedi te..
cmq dividi le pagine in frames, minimo 3.
Ciao
--
--
Fabrizio Parrella
http://www.bibivu.it
TWiN