Just an idea I came up with ad midnight while bottle feeding my daughter. Comments?
Future dreaming
============
I've just finished all the whitepapers on the new V10 ProDataSet and I thought that it would be really nice if you could use that as an interface to Oracle or SQL Server etc. Maybe it would be possible to have each ProDataSet "own" part of the schema (say the customer table) and have the "schema holder" information stored inside the ProDataSet somehow rather than needing a separate schema holder database. Anyway, here are some ideas. Some of this may be impossible or impractical but I'm throwing it out there in case anyone thinks it’s a good idea.
Ideal World
========
It might be very optimistic but what would be really nice is to have a new ProDataSet along the same broad lines as Hibernate in Java (http://www.hibernate.org/). We control what we want the data to look like and the ProDataSet handles how it’s implemented underneath. That way we could be completely database independent and the ProDataSet handles everything there is to know about the data storage and includes the smarts/optimisations for the different database platforms.
Now / Oracle
==========
Summary
---------
I’d see the best method is to create a series of ProDataSets that "own" underlying tables – just like a data abstraction layer so all access to the data is via ProDataSets. This would require the Data Server logic to be put into the ProDataSet and have it contain the necessary mapping information that would normally be in the schema holder database. This removes the need for the schema holder and Data Server all together and keeps the data logic in the ProDataSet where it really belongs.
Details
-------
Lets say the ProDataSet owned the customer table. This would work as normal on the Progress database. If however we went to Oracle, rather than having a schema holder database, this information could be stored in the ProDataSet definition. The ProDataSet therefore contains the information necessary to map a "for each customer" to either Oracle or Progress itself. The queries to fill and save the customer data back to the underlying database in most cases won’t use any of the non-supported or poor performing commands like "find first" so it should be easier to limit the scope of support. Other not supported commands, like "contains", could then operate over this ProDataSet rather than the underlying database itself. Obviously in the case where this is an issue, the changes required to be made to the underlying supporting code would only need to be made in the ProDataSet and no longer across a large code base that is tightly tied to the Progress DB.
Also, if required, different parts of the system could be in different databases, for example the customers could be SQLServer (via its ProDataSet) while the order information is in Oracle (again via its ProDataSet). The databases themselves should be able to be changed without needing to change the ProDataSet, it should be able to map to a different database with little or no effort.
Anyway, thats enough midnight ramblings.
Murray
Future dreaming
============
I've just finished all the whitepapers on the new V10 ProDataSet and I thought that it would be really nice if you could use that as an interface to Oracle or SQL Server etc. Maybe it would be possible to have each ProDataSet "own" part of the schema (say the customer table) and have the "schema holder" information stored inside the ProDataSet somehow rather than needing a separate schema holder database. Anyway, here are some ideas. Some of this may be impossible or impractical but I'm throwing it out there in case anyone thinks it’s a good idea.
Ideal World
========
It might be very optimistic but what would be really nice is to have a new ProDataSet along the same broad lines as Hibernate in Java (http://www.hibernate.org/). We control what we want the data to look like and the ProDataSet handles how it’s implemented underneath. That way we could be completely database independent and the ProDataSet handles everything there is to know about the data storage and includes the smarts/optimisations for the different database platforms.
Now / Oracle
==========
Summary
---------
I’d see the best method is to create a series of ProDataSets that "own" underlying tables – just like a data abstraction layer so all access to the data is via ProDataSets. This would require the Data Server logic to be put into the ProDataSet and have it contain the necessary mapping information that would normally be in the schema holder database. This removes the need for the schema holder and Data Server all together and keeps the data logic in the ProDataSet where it really belongs.
Details
-------
Lets say the ProDataSet owned the customer table. This would work as normal on the Progress database. If however we went to Oracle, rather than having a schema holder database, this information could be stored in the ProDataSet definition. The ProDataSet therefore contains the information necessary to map a "for each customer" to either Oracle or Progress itself. The queries to fill and save the customer data back to the underlying database in most cases won’t use any of the non-supported or poor performing commands like "find first" so it should be easier to limit the scope of support. Other not supported commands, like "contains", could then operate over this ProDataSet rather than the underlying database itself. Obviously in the case where this is an issue, the changes required to be made to the underlying supporting code would only need to be made in the ProDataSet and no longer across a large code base that is tightly tied to the Progress DB.
Also, if required, different parts of the system could be in different databases, for example the customers could be SQLServer (via its ProDataSet) while the order information is in Oracle (again via its ProDataSet). The databases themselves should be able to be changed without needing to change the ProDataSet, it should be able to map to a different database with little or no effort.
Anyway, thats enough midnight ramblings.
Murray