Good morning,

you make a real hit!

/>The database for Company A should have all the tables used by the
users in Company A, including the low-volatility ones like your/

/>Municipalities table. If Comapny B needs Municipalities, it should
have its own copy. //_
_/

/_>You can create a DML script _//for this low-volatility table and run
it over each database.../

You have answered to the question that I have turned some days ago, but
I don't know how to do.

What it means "low-volatility"? without "consistency"? To create a
temporary "vew" to utilize as a table to join? Can you explain me the
concept, even with an example? I think that the problem (always for me)
is to utilize the table of the second database in the same transaction
of the table of the first database...

I thank for the devote time, perhaps the question is "a little banal"...
(^_^)

I cordially greet

Antonio BIANCA


Il 18/09/2018 00:27, Helen Borrie helebor@...
[firebird-support] ha scritto:

>
> Antonio,
>
> > 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?
>
> So far, so good.
>
> > 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;
>
> Yes, one client (Company A) one database
>
> > - different clients ask me different types of programs: FOR ME, a
> > database must be created (drawn) for each type of program;
>
> For everyone else, a database is created for each client organisation
> (one database for Company A, one database for Company B, and so on.
>
> > - 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;
>
> The database for Company A should have all the tables used by the
> users in Company A, including the low-volatility ones like your
> Municipalities table. If Comapny B needs Municipalities, it should
> have its own copy. You can create a DML script for this
> low-volatility table and run it over each database; or use a
> replication tool if it is called for.
>
> > (2) the same "table" can be repeated
> > in all the databases;
>
> That is what I referred to as "spreadsheet". Those old-style desktop
> fielsystems predated spreadsheets and lent themselves to that model of
> application, due to explicit table locking. That does not make it a
> sensible or correct approach for a transactional RDBMS such as
> Firebird.
>
> > - 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;
>
> No, all tables should be available to all progrms and to one another.
> If you have the same data in more than one table, you have redundancy,
> the big enemy in data management. Related to this, if you are using
> actual data as keys, you have intrinsic redundancy.
>
> If you want to prevent certain USERs or ROLEs from accessing certain
> tables, you use SQL privileges.
>
> > - 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!!
>
> Firebird is designed to ensure the ACID rules (Atomicity, Consistency,
> Isolation, Durability). it won't prevent you from breaking those rules
> but it won't heal your wounded data for you, either.
>
> > 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!!
>
> Actually, every database is part of a management system of one kind or
> another, so you are not alone in this world. You can design a system
> to store data according to rules and structures that make it safe and
> smart: THAT is the purpose of a RDBMS. Apparently, you want to follow
> the spreadsheet model, in which a single set of data is exclusive to a
> single application. So - you maintain multiple instances of the same
> data by hand and say your prayers.
>
> > From this my problem is born, but I can change my formulations.
> > I need to think.
>
> If you are unfamiliar with the ACID rules and normalization, look them up.
>
> 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