Hi, I have a question about the following paragraph of Ceki's comments:
Once we settle on the best representation of the table, I think a table structure (table name and column names) should be fixed once and fall all. This would allow other components to query the database and present the results to the user in a convenient form. This cannot be done if the underlying table name and columns are not fixed. Is it really necessary for the table name and column names to be 'fixed once and for all'? I have experience with writing and supporting hundreds of reports written with Paradox, Crystal, and Oracle. Basing the reports on database views, rather than the tables themselves, has provided numerous benefits. Here are the two big ones: 1. It isolates the report from the underlying database model. The database administrators are free to name/rename tables and columns and even redefine the columns as long as the view is still valid. These 'report views' usually have a suffix such as 'RPTVW' added to the name as an indicator to data modelers that there are non-database objects that depend on them; this greatly reduces the number of reports that are broken by data model changes because the person making the changes wasn't aware of the dependencies. 2. The datasource for reports can be changed by redefining the view without having to modify the report itself. As long as the view returns a result set that has the same columns, of the same type and in the same order the data can come from any server, any table or even a file. This also allows the report developer, who may not be a database developer, to create and test the report even though the actual data source may not be defined or available yet. A database developer can 'dummy up' the necessary view. The important thing, in my view, is not the use of views per se but the isolation of the database from the processes interacting with the database. If a component really needs to work with 'fixed' items the table (or view) name and column name information could be provided by values from a property or XML file that maps the 'fixed' items to the actual database items? A 'mapping' table could also be used. This would be a table in the database that provides 'metadata'. I use custom metadata tables to provide the column names that the reports should use and to provide size information to JSPs so that data can be displayed in the proper size 'EDIT' or other area on a web page: info such as display-width, actual-width, default value, required. It might be better to get the JDBC appender 'process' ironed out first and worry about the implementation details of the database related objects once the process is working as desired. Rick
