Newsgroup: it.comp.software.database
Titolo: db firebird: usare tabelle di db differenti

Ciao a tutti,
mi ponevo un quesito sulla modalità di uso di firebird.
Un db firebird è contenuto in unico file ed ho letto in rete che la
dimensione massima (teorica) è di 4Gb. A questo punto mi chiedo se
esiste la possibilità di suddividere le tabelle su file differenti( ma
penso proprio che sia possibile) e come si fa. In base alla poca
conoscenza che ho non mi sembra tanto facile, ad esempio, eseguire una
query jointando tabelle fisicamente residenti su due file .fdb
differenti!
Qualcuno sa darmi qualche spiegazione in merito?
grazia a tutti
# vbaRstat #

 Qualcuno sa darmi qualche spiegazione in merito?
Guarda per quanto ho cercato io non ho visto questa possibilità.
Sei sicuro che 4gb di limite non siano dovuti al file system (es. fat32)
più che ad un limite di fb?
Personalmente ho avuto modo di lavorare con archivi di massimo 500Mb(con un
uso massiccio di blob però). Inoltre i database che uso sono .gdb
(interbase).

 (interbase).
Non sono affatto sicuro sui limiti dei  4gb (non riesco a ricordarmi
dove l'ho letto). Una cosa di cui sono più o meno sicuro è  la
possibilità (tramite il comando
CREATE DATABASE 'pippo.fdb'
FILE 'pippo1.fdb') di creare un database composto da più di un file.
Mi chiedevo, quindi, come funzionasse in questo caso la gestione dei
dati dal parte di firebird, ma soprattutto come si fa a jointare tra
tabelle residenti su più file.
Ma pensandoci meglio, forse le tabelle saranno "visibili" tutte sullo
stesso file (pippo.gdb) ma "memorizzate" anche sugli altri. In tale
caso non dovrebbe esserci bisogno di jointare tra tab di db differenti.
Comunque continuo a chiedermi, nel caso avessi due db differenti e,
quindi, due file differenti, posso "collegare" i dati di due tabelle di
cui una residente sul db1 e l'altra sul db2?
 
boh......
# vbaRstat #

 cui una residente sul db1 e l'altra sul db2?
E' quello che serviva a me, alla fine l'ho fatto via codice.
Se ti capita di trovare il metodo fai sapere pure qui sul NG.

 differenti!
grazie al meccanismo visto sopra, se le tabelle fanno parte dello stesso db 
anche se splittato su più file, ai fini pratici non dovrebbe cambiare 
assolutamente nulla.
Se invece intendi che vuoi fare una query di JOIN con tabelle provenienti 
da più database differenti, questo da quanto ne so io (alla versione 1.5) 
non si può fare. Tuttavia ci sono le multi-database transactions (di cui ho 
letto ma che non ho mai usato).
HTH..
-- 
Mauro Falzari 
 
  La teoria è quando si sa tutto ma non funziona niente. 
  La pratica è quando funziona tutto ma non si sa il perchè. 
  In ogni caso si finisce sempre a coniugare la teoria con la pratica: 
  non funziona niente e non si sa il perchè. 
   (Albert Einstein)

 tabelle residenti su più file.
In
http://groups.google.it/group/it.comp.software.database/msg/814929aa623cf492
Marco Kregar riporto` i limiti tecnici di Firebird. Tieni presente,
comunque, che alcuni di quei limiti col tempo sono stati ampliati. Per
quanto riguarda la tua domanda, lo spazio di lavoro e` sempre lo stesso,
indipendentemente dal numero di file che utilizzi (ovvero, se hai una
tabella da 15 milioni di righe, e il db splittato in due o piu` file, e`
probabile che i dati di quella tabella siano spalmati sui due file e,
nonostante questo, tu lavori sulla tabella come se fosse un unico elemento)
Enrico

Enrico "Henryx" Bianchi ha scritto:

grazie enrico per il link che mi hai segnalato e grazie per le
spiegazioni che mi hai dato. In particolare, tralasciando quelli che
sono i limiti teorici, è veramente stimolante leggere come marco
kregar abbia effettivamente lavorato su di un db di 12Gb!!!!!! e
tabelle con 3 milioni di record (alla faccia di chi mi ha detto che per
"applicazioni serie" firebird non "va bene"). Cmq permettetemi di
sottolineare un aspetto forse ovvio e fare una battuta su me stesso :-)
: come sempre la possibilità di fare un buon lavoro non dipende solo
dallo strumento con cui lavori.....ma anche dalla tua capacità di
utilizzarlo :-) (mi rendo conto che con firebird  ho in mano una
ferrari, ma fino ad oggi sono sempre andato a  100Km all'ora.......)
ciao
# vbaRstat #

 Mauro Falzari
ciao mauro grazie per le indicazioni che mi hai dato. In particolare,
mi sapresti dare maggiori informazioni su queste multi-database
transactions di cui parli? Non ho trovato molto in rete....
In pratica mi trovo più db su server e vorrei riuscire a lavorare
collegando tabelle di file .fdb differenti.....
grazie a tutti
# vbaRstat #

 collegando tabelle di file .fdb differenti.....
in poche parole, fare delle query di join su tabelle provenienti da più 
database differenti NON è possibile.
Non lo era nel 2003
http://forums.devshed.com/firebird-sql-development-61/joining-and-copying-
across-multiple-databases-63230.html
e neanche nella Firebird 2.0 Release Candidate 5 pare sia possibile (mi 
sono letto rapidamente le release notes).
Come già detto, se suddividi un database su file differenti (anche su 
dischi differenti), la gestione di FB rende il procedimento assolutamente 
trasparente: è come se avessi un unico file.
Però andando a rileggermi EmbedSQL.pdf (documentazione di Interbase 6.0, 
che era distribuita liberamente da Borland), ho trovato che effettivamente 
si possono realizzare delle applicazioni multi-database (Chapter 3. Working 
with databases: Declaring multiple databases / Controlling SET DATABASE 
scope / Differentiating table names; e poi al capitolo 4: Working with 
multiple transactions / A multi-transaction example [l'esempio fornito è 
però in linguaggio C]). 
Ti ricordo però che tutto ciò fa riferimento al linguaggio Embedded SQL o 
ESQL: si tratta di una serie di istruzioni "SQL-like" che vengono usate 
all'interno di programmi scritti in C o COBOL, prefissate sempre dallo 
statement EXEC SQL; poi il tutto dev'essere preprocessato da gpre.exe (che 
si trova nella cartella /bin della distribuzione di Firebird).
In effetti, un modo per aggirare il problema potrebbe essere l'uso dei 
cursori (statement DECLARE CURSOR, disponibile ancora una volta solo in 
ESQL) e la stessa Helen Borrie dice che per usare i cursori, 
un'applicazione dinamica deve pre-dichiararli usando la funzione 
isc_dsql_set_cursor_name (1) e che mentre alcuni componenti di accesso ai 
dati implementano l'interfaccia verso questa API, la maggior parte (dei 
componenti) non lo fa.
(1) infatti nell'Interbase API Guide (ApiGuide.pdf, rilasciata 
pubblicamente da Borland come documentazione di Intebase 6) c'è la funzione 
isc_dsql_set_cursor_name che "Defines a cursor name and associates it with 
a DSQL statement".
-- 
Mauro Falzari 
 
  La persona che conosce il vostro segreto
  diventerà il padrone della vostra libertà.
    (François La Rochefoucauld, 1613-1680)

..dimenticavo di dire che con Firebird, le applicazioni client possono 
aprire un "qualsiasi" numero di connessioni contemporaneamente verso 
altrettanti database (dipende dalle risorse di sistema del server).


 ferrari, ma fino ad oggi sono sempre andato a  100Km all'ora.......)
Senza offesa, ma questa e` abbastanza forte come affermazione, in quanto
anche Firebird ha dei limiti (e su uno ti ci sei scontrato anche tu)
Enrico

 anche Firebird ha dei limiti (e su uno ti ci sei scontrato anche tu)
Infatti ne ha diversi, dal linguaggio SQL non proprio esteso (anche se con
firebird sono stati introdotti COALESCE e CASE), ad esempio non esiste una
VAL, una right$ (risolvibili con le UDF).
Non supporta l'aggiornamento multiplo, mentre l'insert si
INSERT INTO tabella (campi) SELECT campi1 from tabella1

 trasparente: è come se avessi un unico file.
Io ad esempio ho un programma che sfrutta un archivio anagrafico ed uno
annuale.
Ad esempio la tabella dei comuni è in quello anagrafico, e non posso fare
select dirette.
Fortunatamente via codice o in fase di report si può aggirare.

Mauro Falzari ha scritto:

In sostanza, in una maniera facile facile, fino ad ora ho lavorato
semplicemente con un file access. I db sono in firebird, ma in access
mi creo un insieme di "tabelle collegate" (via ODBC) ai vari .fdb ed in
questo modo mi credo tutte le query che mi interessano (incrociando
dati residenti sui database differenti). La domanda che mi / vi pongo
è questa: voglio evitare il più possibile di far ricorso al motore
Jet di access, ma facendo in questo modo (e scusate l'ignoranza) faccio
lavorare sempre e solo firebird? 
grazie
# vbaRstat #

 INSERT INTO tabella (campi) SELECT campi1 from tabella1
..e marginalmente mi pare che le query di join non siano neanche updatabili 
live, ma tramite una serie di trigger sulle tabelle sottostanti.
I parametri delle stored procedure non supportano i domini (ma questo forse 
con la versione 2 è stato superato).
I campi di tipo testo non hanno il trimming automatico (anche se si può 
supplire scrivendo codice nei triggers).


 Fortunatamente via codice o in fase di report si può aggirare.
in Delphi, scrivere un'applicazione multi-database è piuttosto semplice, 
dal momento che un'applicazione client può aprire connessioni verso un 
qualsiasi numero di database.


dimenticavo...un aiuto molto valido e un ricco archivio di post precedenti 
lo puoi trovare sul NG delphiedintorni.it.database.firebird, sul server 
news.delphiedintorni.it
 (gratuito previa iscrizione su 
www.delphiedintorni.it
)


 lavorare sempre e solo firebird?
Si. Access e` un frontend che di default usa Jet, ma che puo` utilizzare
via ODBC anche altri motori. Lo scotto da pagare, pero`, e` proprio la
connessione ODBC, che aggiunge uno strato tra il frontend ed il backend
Enrico

 Enrico
scusami enrico, aiutami a capire un altro aspetto. Immagina che ho un
db firebird che girerà su server e su di esso vi accederanno al
massimo 3/4 client contemporaneamente. Gli utenti finali non dovranno
in nessun modo scrivere una riga di codice SQL per interrogare il db.
Per tale motivo pensavo di sviluppare un'interfaccia in Access,
aggiungendo (come dici tu) uno strato tra FE e BE. Le mie domande sono:
ma questo strato non è un problema generale che si presenta nel
connettere un qualunque FE (che sia in Access o meno)  ad un db ?
Ossia, il problema sarebbe differente se, ad esempio, sviluppasi il FE
in delphi (o altro) ?
La connessione non sarebbe sempre ODBC? (,,,data la mia ignoranza
immagino l'esistenza di altre vie.... :-)
ciao e grazie per questa interessantissima discussione :-)
# vbaRstat #

 immagino l'esistenza di altre vie.... :-)
OleDB ad esempio :) con Ado quindi.

 qualsiasi numero di database.
Anche con VB6, due variabili di tipo ADODB.Connection e via, solo che non
fai query manualmente con un unico recordset.

 
www.delphiedintorni.it
)
Dici che è utile anche se uso VB6?
Tnx

 Tnx
certo, perchè è un gruppo dove si parla solo di Firebird. Per altri 
argomenti (Delphi, Interbase...) ci sono aree diverse


 "applicazioni serie" firebird non "va bene"). 
Se ti può essere utile ti dico che io ho lavorato su 5 DB differenti di 
9 GB e 14 milioni di record l'uno, non ho avuto la minima difficoltà e 
tempi di risposta per query "medie/complesse" intorno ai 3/4 minuti
Massimo

 immagino l'esistenza di altre vie....
Come detto, hai molte vie, ognuna dipendente dal linguaggio e dal sistema
utilizzato. Per esempio, Access, oltre ad ODBC come sistema di
interfacciamento al database, dovrebbe permetterti l'utilizzo di driver
ADO che, se non ricordo male, dovrebbero permettere una connessione
diretta al database (personalmente non ho mai provato ad utilizzarli).
L'unica via generica, da questo punto di vista, e` ODBC, in quanto la sua
unica dipendenza e` data dall'avere un driver ODBC per il database scelto
Enrico

 On Wed, 11 Oct 2006 00:35:18 -0700, # vbaRstat # wrote:

grazie enrico, sei stato chiarissimo :-)
# vbaRstat #

grazie massimo per l'informazione!!! :-)
ciao
# vbaRstat #
Tin ha scritto:
