Package Proposal: DB_Catalog_SQL

This package uses a catalog of a database layout to build SQL compliant select statements, insert statements, and delete statements based on an array of data passed to the corresponding function. This is a foundation object used by others to respond to an environment where the database layout is not know. This may be in cases like an reporting subsystem or to tie the quick_forms packages to a datastore to automagicly pull data from or store data to a SQL compliant datastore. The administrator reads in or inputs the database information, tables, fields, and then enters the join criteria into a database. The tables and fields are then linked to a catalog. Every catalog, table, field, joinstatement is assigned a unique id and all relations are internally referred to by that ID. Also, every field and table has the ability to be staticly aliased. This way, two tables can be linked multiple times. For instance, a table where the state is stored in two different fields can be related by defining the state lookup table twice, aliasing the table, then using the "virtual" tables in the relation. Several functions use this information to build appropriate SQL statments based on the request. All tables are internally aliased, and relationships are resolved, even where they are indirect. For instance, a request to build_select for table1.field1 and field2, and table3.field3 and field4 where field4 = 7 might return: "select z.field1, z.field2, x.field3, x.field4 from table1 as z left join table2 as y on z.field7 = y.field8 left join table3 as x on field y.field 9 = x.field3 where field 3 = 7" The rough implementation of the core library functions are attached. They do not meet the formatting standards, but I will be happy to fix them if the package is accepted. Also, there are some other nuonces that need to be addressed. Still to come is a management interface and functions to read the db structure automaticly from the database. Thanks, Rob