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 hele...@iinet.net.au [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
