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
