He, Helen, I don't understand as you have been able to believe that I have treated a database as was a spreadsheet!!! I know what is a table, a database (database as "set of tables", database as "file of type database"), a relation, a key, an inedex, a... I've studied on your book.
When I speak "to draw a table" for a program, I intend to set various "tables" with the appropriate fields (name and type) and the relationships with the fields of other "tables": so the database is the whole organized of these "tables" and relations. Right? if it is not correct, I go to be a carpenter... else - a client ask me to write a program for a single scope, the archives (the "tables" in the database!) must be able to contain the data related to that type of activity and I draw (create, write) a dabatase with the correct tables; - different clients ask me different types of programs: FOR ME, a database must be created (drawn) for each type of program; - two or more programs can have some identical "table" (e.g. municipalities); - (1) I can create apart a unique database of "common tables" for the "tables" used by all the programs; (2) the same "table" can be repeated in all the databases; - it could be created an only database for all the programs; for every new program, new "tables" can be added in this unique database, while the "table" existing can be used by the new program; - if you write dozens of programs (very small, normally, very great), the only database becomes not manageable, *but it doesn't behave problems*. "not manageable" FOR ME as administration of the variations to the single fields: Firebird is able of to manage millions of tables and relationships, I can't, is its purpose!! You pursue a purpose of general relations, that is the purpose of DBRMS; I pursue a purpose of management USING Firebird and its capability to relate: it is not the same thing! FOR ME, naturally!! From this my problem is born, but I can change my formulations. I need to think. Thanks for the devote time : you must also work... Best regard Antonio BIANCA Il 15/09/2018 07:16, Helen Borrie hele...@iinet.net.au [firebird-support] ha scritto: > > Antonio, > > > I'm agree with you: all tables in a unique firebird file is the best > choice. > > > My problem is that I've numerous programs that utilize one firebird file > > each. > > That problem is easy to solve. Place all of the tables in one > database and use an alias for that database in every application. > > > There are tables that are drawn for a specific program, but there are > > some tables that are "common" to all programs (example: > > "municipalities"). An user can utilize one program, two programs, four > > programs, and so on, on the same computer and each program hav its > > database.fdb: if I must vary a value of one "common tables", I must send > > an update for every program and to each user; but if the "common tables" > > are in a unique, separate database, I can update one file only. > > This is not a database design. You are treating "database" and > "spreadsheet" as though they were the same animal. Very definitely, > they are not the same. > > Think "relational", because Firebird is a relational database system. > Tables (a.k.a. relations) can be *related* to one another by way of > foreign keys. Data from tables containing compatible fields (columns) > can be connected during run-time queries by JOINs or UNIONs. > > > There are also "static" tables containing storical movements, and is not > > necessary periodically to back-up them. > > At the same time, it does no harm for them to be included in the > backup of your current data. It makes sense for them to be in the > same database as the active tables if you need to refer to them from > your applications. > > > These are the reasons that push me to look for a solution, I hope to > > have been clear. > > The thing that seems clear to me is your confusing "tables" with > "databases". The whole point of using a relational database is to > have all of the interrelated data available to each individual client > connection. > > > For release 2.5 and not 3.o, I have been studyng Firebird for some > > months, and I've not experience: I now plan the job to develop, later I > > will verify the new releases. > > The question of whether you use 2.5 or 3.0 is not relevant to your > problem. Spend some more time understanding how a relational database > works - and forget your preconceptions from previous work you have > done using spreadsheets or fiel-based data storage systems. > > Helen > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus
