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 helebor@...
[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