Hi!
I guess the Rel Catalog is where all the metadata about the relvars (its contraints, etc) in a Rel database are stored... I guess currently this is stored using Berkeley DB... that makes me think, that if we want to give Rel the ability to be a T/PRM (True /PseudoRelational Mapper) it should also be able to store this catalog information in the mapped pseudo relational database....
On the other hand, one of the know Sql Flaws is that sometimes DBAs become overprotective with their databases, and do not allow anyone to add anything they do not fully understand... therefore, it should be possible to have this Catalog in the same database... or in a different one.
What are your thoughts/plans on this?
Regards,
Rel Catalog over JDBC
Re: Rel Catalog over JDBC
My feeling is that metadata about an external SQL database should be housed in a native Rel database. In other words, there will always be a native Rel database, and external SQL tables (including metadata) will be represented as relvars within the native database.
Re: Rel Catalog over JDBC
Hi!
I agree with you that the best option for the Rel Catalog could be a native Rel database.... (on the other hand, what should be done withe the relvars of the Catalog of the Catalog? I sense some kind of weird recursion going on here)...
But I also think it should be designed so that the underlying storage mechanism is pluggable.... why? well, I (and many DBAs I know) love the idea of simply having to "backup" the Oracle/SqlServer/Db2/Whatever database without worrying about losing some data, in other words, if Rel is able to store the Catalog in the same database, the user will have less stuff to worry about when doing maintenance (if I backup my core Oracle/SqlServer/Db2/Whatever database I know I don't need to worry about backing up anything else).
On the other hand, I can see the advantages of having an external Catalog (in could be used, for example, to recreate a clean pseudo relational database from scratch when the system is installed the first time)
Regards,
LuxSpes
I agree with you that the best option for the Rel Catalog could be a native Rel database.... (on the other hand, what should be done withe the relvars of the Catalog of the Catalog? I sense some kind of weird recursion going on here)...
But I also think it should be designed so that the underlying storage mechanism is pluggable.... why? well, I (and many DBAs I know) love the idea of simply having to "backup" the Oracle/SqlServer/Db2/Whatever database without worrying about losing some data, in other words, if Rel is able to store the Catalog in the same database, the user will have less stuff to worry about when doing maintenance (if I backup my core Oracle/SqlServer/Db2/Whatever database I know I don't need to worry about backing up anything else).
On the other hand, I can see the advantages of having an external Catalog (in could be used, for example, to recreate a clean pseudo relational database from scratch when the system is installed the first time)
Regards,
LuxSpes