Newsgroup: it.comp.www.php
Titolo: [OT] Come importare un archivio del genere?

Sono 2 ore che mi scervello senza trovare una soluzione degna di questo 
nome...
Devo importare questo archivio (scaricabile in DBF) 
http://borsa.granariamilano.org/
 in un archivio MySql, in modo che poi 
sia possibile utilizzarlo come un'anagrafica articoli.
La cosa brutta è che devo mantenere un archivio storico (come sul sito), 
  e che nel DBF, come potete notare, non c'è assolutamente un codice 
articolo o un indice :(
Sulle prime avevo pensato di usare l'unica cosa usabile, cioè la 
descrizione, e fare una tabella di transcodifica con la mia tabella 
articoli... peccato che ci siano più descrizioni uguali (ROMA, BALDO per 
esempio), quindi dovrei tener conto anche della "categoria" in cui sono.
Però non è che sia così contento da tenere DUE tabelle di 
transcodifica... anche perché poi sarebbe compito del cliente mantenerle 
aggiornate, con tutti i casini che questo potrebbe generare.
Se avete voglia e tempo di dare un'occhiata, vi ringrazio in anticipo... 
intanto continuo a elucubrare.
(ma si può nel 2009 dover combattere con delle cose fatte così alla 
cazzo di cane???)
-- 
Jax

 aggiornate, con tutti i casini che questo potrebbe generare.
Lasciate perdere, tanto mi sa che l'unico modo è, come dicevo, tenersi 
in memoria l'ultima categoria letta e scriverla sul record insieme al 
componente, in modo da avere un indice univoco, seppur descrittivo (che 
mi fa alquanto schifo).
Grazie anche solo per aver letto.
-- 
Jax

sia possibile utilizzarlo come un'anagrafica articoli.
Te lo leggi come lista CSV di record.
La categoria la trovi per accumulo:
	$fp = fopen('listino.csv', 'r') // o altro per leggere i DBF
	// Leggi l'intestazione e la scarti
	while(!feof($fp))
	{
		$recs = get_record($fp);
		if ('' == $recs[0])
			continue;
		if ('' == $recs[1])
		{
			// Categoria
			$cat = $recs[1];
			continue;
		}
		// Ora ho $cat e $recs[0] che contengono
		// il mio articolo.
		$id = get_id($cat, $recs[0]);
		...
		// Non inserisco $recs[1] e $recs[2] perche' dovrei
		// averli gia' inseriti la settimana scorsa. Potrei
		// pero' controllare che ci siano, a scanso errori.
		// Oppure potresti fare un INSERT IGNORE, basandoti
		// sulla data calcolata dalla colonna.
		// INSERT INTO storico ($data1, $id, $recs[1], $recs[2]);
		INSERT INTO storico ($data2, $id, $recs[3], $recs[4]);
	}
get_id riceve per esempio ('RISONI', 'ARBORIO') e li cerca nella tabella
articoli (id, categoria, articolo). Se NON lo trova lo inserisce. Poi ti
ritorna comunque l'id.
Con questo sistema, avrai una tabella articoli (data, id, min, max) poco
ingombrante e con indice univoco.
La "manutenzione" e' automatica :-)
Leonardo
-- 
And where the black and corkscrew towers climb,
Lost and athirst the ragged pack abides,
Old as the aeons, trapped in tombs of time,
Sailing the tortuous temporal tides

 ingombrante e con indice univoco.
Infatti ho già provveduto in tal senso, e ho una tabella univoca (anche 
se su campi testuali) con anche lo storico (la data del listino).
Il mio "problema" è che devo comunque mantenere un'altra anagrafica 
componenti, legata a questo listino ma indipendente (ci saranno anche 
componenti non presenti in questo listino), quindi l'unica cosa che 
posso fare è avere dei componenti "virtuali" legati dinamicamente ai 
componenti del listino: l'unico modo è specificare nella tabella 
componenti "mia" qual è la categoria e la descrizione del componente del 
listino Granaria. Non è una gran soluzione, ma penso che possa 
funzionare. In fondo, una volta impostata, questa tabella dubito che 
verrà movimentata molto.
In questo modo, oltretutto, ho una sola anagrafica componenti, sia per 
quelli nel listino che per quelli "manuali".
Ad ogni modo grazie. Penso che ci rileggeremo presto sul ng :)
-- 
Jax

funzionare.
Certo che funziona; perche' non e' una gran soluzione? Basta blindare
la fase di immissione articoli.


 componenti del listino:
Sai che ancora non ho capito quale sia il problema?
A quanto ho potuto leggere hai questo listino A e ne hai un altro B 
"legato ma indipendente"in cui gli elementi di A possono comparire o 
meno.

 meno.
Alla fin fine, l'unico problema me lo faccio io :)
Scherzi a parte, il mio unico dubbio è che devo "linkare" un articolo 
del listino A con un articolo del listino B mediante campi testuali (ma 
anche se dovessi generare un id sarebbe comunque basato su questi due 
campi testuali), perché ho solo quelli a disposizione: se un domani alla 
Granaria si inventassero di cambiare una descrizione di un componente o 
di una categoria?
-- 
Jax

 la fase di immissione articoli.
Infatti blinderò il tutto con delle combobox da cui scegliere categoria 
e descrizione, valorizzate mediante select distinct... niente campi 
testuali liberi.
Grazie ancora.
-- 
Jax

 di una categoria?
Usa un attributo fittizio come chiave, con buona pace delle descrizioni.

 Usa un attributo fittizio come chiave, con buona pace delle descrizioni.
Che attributo fittizio dovrei usare?
Forse mi sono spiegato male (non è neanche facilissimo da spiegare).
Il fatto è che il mio articolo "Riso Arborio" dovrà sempre essere legato 
all'articolo "RISONI/ARBORIO" del listino Granaria (o meglio, di *un* 
listino scelto tra le varie date).
Però nel listino non ho un codice, quindi posso solo dire che al mio 
"Riso Arborio" (che avrà il suo ID) dev'essere legato l'articolo 
"RISONI/ARBORIO" (specificandone proprio la descrizione).
Se un domani questi si inventano di cambiare "RISONI" in "RISOTTI" sono 
fregato perché perdo il legame tra i due articoli.
Niente di grave ovviamente, basta una SQL di update... però più ci penso 
e più vedo che non ho altre strade.
PS: Certo che il "pisello proteico" è fenomenale :)
-- 
Jax

prezzo).
No, ce ne avresti uno solo (che so: "RISONI/ROMA" o "RISONI/ARBORIO").
La funzione get_id($cat, $art) riceve 'RISONI', 'ROMA' ed effettua una
SELECT nella tua anagrafica master cercando per es.
	WHERE articolo='GRANARIA $cat/$art'
e se lo trova, ti ritorna l'ID, se non lo trova lo inserisce ed ancora
ti ritorna l'ID. Ma nell'anagrafica esistera' comunque un articolo, ed
uno soltanto.


fregato perché perdo il legame tra i due articoli.
Aaaaah, mi mancava questo.
Okay, carichi una volta il listino e poi se la funzione get_id non trova
niente nell'anagrafica master, chiede aiuto.
    ("Found unexpected RISOTTI/ARBORIO, please contact tech support")


     ("Found unexpected RISOTTI/ARBORIO, please contact tech support")
Esattamente quello che ho fatto (solo che l'ho scritto in italiano) :)
Grazie a tutti e due per il supporto.
-- 
Jax

 PS: Certo che il "pisello proteico" è fenomenale :)
Forse con molta palestra e curando bene l'alimentazione.

 Che attributo fittizio dovrei usare?
Se non ricordo male come funzionavano DBIII e parenti, mi sembra che il 
problema nasca dal trattare il file DFB come se fosse la tabella di un 
DB relazionale, cosa che DBIII non era.
In pratica, la chiave primaria delle tabelle era la posizione del 
record, che rimaneva inalterata a parte compattazioni, e la navigazione 
era per lo più fatta andando avanti e indietro con dei cursori.
Quindi, penso che tu possa trasferire il numero di record del DBF come 
campo chiave sulle tabelle MySQL e ricostruire le relazioni.
Ciao.

spazza ha scritto:

Avevo pensato anche questo: purtroppo ho visto che nel tempo hanno 
aggiunto/tolto dei componenti, facendo sfasare tutte le righe sottostanti.
Oppure mi stai dicendo che se viene inserita una riga nella tabella, 
questa prende un nuovo numero di record? Esempio:
NRR - DESCRIZIONE
1   - Record uno
2   - Record due
3   - Record tre
se inserisco una riga tra il record 2 e 3, come sarà la sequenza?
1   - Record uno
2   - Record due
4   - Record quattro
3   - Record tre
oppure
1   - Record uno
2   - Record due
3   - Record quattro
4   - Record tre
Nel primo caso sarebbe perfetto, ma come lo tiro fuori il "vero" numero 
di record dal DBF?
-- 
Jax

 3   - Record tre
Ripeto "se non ricordo male", mi sembra che sia proprio così, e anzi, li 
vedi nell'ordine dell'esempio perché da qualche parte è definito un 
indice di presentazione (file .ndx, mi sembra), altrimenti li vedresti 
nell'ordine di inserimento, a meno di un'operazione (mi sembra pack o 
zap o qualcosa di simile) che rimuove i "buchi" prodotti dalla 
cencellazione di record.
Per ricavare il numero di record, dovrebbe essere sufficiente leggerli 
nell'ordine di default con le funzioni di PHP.
Qui però comincio a brancolare nel buoi, saranno 10 anni che non tocco 
un file DBF.
Ciao.