popolare database

[tigh]

intanto ciao a tutti , leggo spesso questo forum per risolvere problemi e cercando qua e là ho sempre trovato la soluzione.. ma non questa volta.

quindi ecco la domanda:
ho un database costituito in questo modo. ho una serie di progetti ad ogni progetto appartengono una serie di oggetti e ad ogni oggetto sono associati alcuni file. le 3 tabelle del database sono così fatte:

tabella progetti:
id_project(primary key che si autoincrementa), nome_progetto , descrizione

tabella oggetti:
id_object (primary key che si autoincrementa) , nome_oggetto , descrizione, id_project

una tabella file:
id_file (primary key che si autoincrementa), path del file, id_object, id_project


per esempio:

tabella oggetti:
id-object | name_object | descrizione | id_project
1 ...........xyz ...............bla bla bla...........1
2 ...........klm ...............bla bla bla ..........1
3...........pippo.............bla bla bla............1

tabella file:
id_file | path del file | id_object | id_project
1........./dfg/hsdg.........1................1
2........./dfg/hsdg.........1................1
3........./dfg/hsdg.........1................1
4........./dfg/hsdg.........2................1
5........./dfg/hsdg.........2................1
6........./dfg/hsdg.........3................1
7........./dfg/hsdg.........3................1
8........./dfg/hsdg.........3................1

vorrei trovare un modo sensato per popolare il database con nuovi progetti (uno alla volta) possibilmente leggendo i dati da dei file di testo e facendo in modo che il campo id_project nella tabella oggetti sia automaticamente settato uguale al valore della chiave progressiva id_project della tabella progetti.
stessa cosa per valori dei campi id_object e id_project nella tabella file...

intanto vi pare sensato come modo di procedere e poi nel caso come fareste (con uno script sql, con uno script php, strutturati come...?)
grazie in anticipo

tigh

[ntd]

Originariamente inviato da tigh
tabella progetti:
id_project(primary key che si autoincrementa), nome_progetto , descrizione

tabella oggetti:
id_object (primary key che si autoincrementa) , nome_oggetto , descrizione, id_project

una tabella file:
id_file (primary key che si autoincrementa), path del file, id_object, id_project

La struttura è buona, a parte il campo "id_project" nella tabella "file" che è ridondante e quindi da eliminare (se hai già l'id_object sai già anche l'id_project). I campi id tendo a metterli all'inizio della struttura perché è più efficiente nel caso di record voluminosi o a lunghezza variabile.

Quanto al metodo di importazione userei il comando SQL 'LOAD DATA INFILE' che agisce (molto velocemente) su file di puro testo. Dacci un'occhiata nella documentazione di MySQL (o chi per lui).

[tigh]

intanto grazie ntd, è vero che id_project nella tabella file è ridondante! non ci avevo pensato...

per quanto riguarda l'inserimento anche io stavo pensando a LOAD DATA INFILE.
quello che mi chiedevo però è se esite un modo per inserire i dati, diciamo, a cascata.

cioè:
- inserire i dati di un nuovo progetto nella tabella progetti
- inserire gli oggetti di questo nuovo progetto nella tabella oggetti e fare in modo che il campo id_project assuma il valore del progetto in questione.
- per ogni oggetto inserire i percorsi dei file corrispondenti nella tabella file facendo in modo che l'id_oggetto assuma il valore corrispondente...

spero di essermi spiegato decentemente...
grazie e ciao

[ntd]

Originariamente inviato da tigh
per quanto riguarda l'inserimento anche io stavo pensando a LOAD DATA INFILE.
quello che mi chiedevo però è se esite un modo per inserire i dati, diciamo, a cascata.

Bè, LOAD DATA INFILE è abbastanza flessibile: puoi assegnare dei valori di default. Mettiamo che la tabella "oggetti" è composta da "id", "progetto", "nome", "descrizione" e tu hai un file di testo "oggetti.txt" col tracciato:

"nome","descrizione"

ma sai che fanno tutti parte del progetto 1.

LOAD DATA INFILE 'oggetti.txt'
INTO TABLE oggetti
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n'
(nome, descrizione)
SET progetto = 1

Noti le potenzialità di LOAD DATA INFILE?

[tigh]

però se volessi passare a SET non un valore predefinito ma una variabile dovrei inserire il tutto all'interno di un codice php giusto?

cioè io non vorrei dovermi preoccupare di qual è il valore di id_project o id_object,
vorrei invece:

1. inserire i dati del progetto nella tabella progetti, andare a leggere l'id progressivo assegnato (id_project), metterlo in una variabile e usare poi SET con quella variabile per scrivere nella tabella oggetti ... se si può fare.

2. vorrei poi fare la stessa cosa con gli oggetti ovvero: leggere dal file oggetti il primo oggetto inserirlo nel db, leggere dal db l'id progressvo (id_obj) che gli è stato asseganto e metterlo in una variabile.

3. quindi leggere dal file "file" i dati da inserire e scriverli nella tabella file assegnando con SET l'id_obj letto prima...

quindi ci sarebbe il codice SQL per gestire le query e attorno una struttura php per gestire i cicli... qualcosa del genere...

ovviamente il casino è il file con scritti i path... perché bisogna trovare un modo per separare i dati dei diversi oggetti, mettere qualcosa tipo leggi riga per riga, se trovi 0 torna al punto 2 (questo perché non è detto che tutti gli oggetti abbiano associati lo stesso numero di file...)

il file da cui leggere i dati potrebbe essere qualcosa tipo:

path/nome file
path/nome file
pat/nome file
0
path/nome file
path/nome file
path/nome file
path/nome file
0
path/nome file
path/nome file
path/nome file

però in questo caso non potrei usare LOAD DATA INFILE credo... perché non mi permette di leggere un file riga per riga...
... che casino

in ogni caso grazie per l'interessamento!

[tigh]

ok alla fine ho deciso per il LOAD DATA INFILE per le tabelle "oggetti" e "file" e usando SET per il campo proj_id...

quindi i file per l'aggiornamento saranno così strutturati

oggetti:
nome, descrizione

file:
path, id_oggetto

visto che il database dovrà essere aggiornato con due o tre nuovi progetti nuovi all'anno non di più probabilmente è la cosa più sensata anzich'è impazzire per cercare un modo per fargli scrivere automaticamente l'id_oggetto corretto...

un'altra domanda: io ho pensato la tabella "file" per potervi inserire il path dei file e non i file veri e propri, ho letto in giro che questa è la scelta migliore.... è vero?

[ntd]

visto che il database dovrà essere aggiornato con due o tre nuovi progetti nuovi all'anno non di più probabilmente è la cosa più sensata anzich'è impazzire per cercare un modo per fargli scrivere automaticamente l'id_oggetto corretto...

Saggia decisione.

io ho pensato la tabella "file" per potervi inserire il path dei file e non i file veri pe propri, ho letto in giro che questa è la scelta migliore.... è vero?

No, non è vero: è solo la più semplice.

Devi valutare a seconda delle tue esigenze. Per esempio, se i files ce li hai già sul filesystem o vuoi vederli anche senza MySQL, registrare solo il link è la soluzione più ovvia e naturale. Se invece hai molti files (nell'ordine delle migliaia) e accedi solo con MySQL, registrarne il contenuto direttamente nel database è sicuramente la soluzione più efficiente.

[tigh]

diciamo che ogni progetto sarà composto da circa 100-200 file.
per ora ci sono solo due progetti, potrebbero aggiungersene appunto 2-3 all'anno.

un'altro aspetto è che i file possono avere dimensioni molto disomogenee da 1Mb a più di 500Mb... e magari anche di più non posso saperlo in anticipo...

quindi pensavo che visto che andranno tutti nella stessa tabella fosse più efficiente caricare solo i percorsi che dover usare un campo LONGBLOB per tutti... non so se sto dicendo cose sensate...

[ntd]

Originariamente inviato da tigh
diciamo che ogni progetto sarà composto da circa 100-200 file.
per ora ci sono solo due progetti, potrebbero aggiungersene appunto 2-3 all'anno.

un'altro aspetto è che i file possono avere dimensioni molto disomogenee da 1Mb a più di 500Mb... e magari anche di più non posso saperlo in anticipo...

quindi pensavo che visto che andranno tutti nella stessa tabella fosse più efficiente caricare solo i percorsi che dover usare un campo LONGBLOB per tutti... non so se sto dicendo cose sensate...

Sì. Più in generale, diciamo che il filesystem è molto efficiente con pochi files di grandi dimensioni mentre un database server è più indicato con molti files di piccole dimensioni.

[tigh]

Originariamente inviato da ntd
Sì. Più in generale, diciamo che il filesystem è molto efficiente con pochi files di grandi dimensioni mentre un database server è più indicato con molti files di piccole dimensioni.

capito...
e io ho un bel miscuglio delle due cose, la maggior parte dei file sono di piccole dimensioni ma alcuni sono grandi...