dbptk-developer
dbptk-developer copied to clipboard
keeps
Choosing view or table when converting SIARD back to database
I'm trying to understand the options around views and whether or not to materialise them when creating a SIARD. For the broadest possible compatibility it is probably wise to materialise views when initially creating a SIARD package. However, if you then wish to recreate the database in the original RDBMS later it would nice to be able to choose just to recreate the view based on the SQL originalquery stored in header->metadata.xml rather than ending up with a table. Changing to a table means that you haven't really preserved the original database structure, though this may be necessary for conversions between different RDBMS. From the currently available documentation I can't quite work out if this would be something made possible by the things mentioned in #414 and #415 or not?
Hello,
I´m already discussing these questions with my colleagues in Czech Republic. Materialised view is useful feature but has negatives too. What about to preserve original database splitted on parts? Original db and materialised views. Idea is not my [https://github.com/DILCISBoard/SIARD/issues/32 (url).
When materializing a view, we still keep the view, but we also create a table called VIEW_nameOfView.
When exporting to a DBMS, both the original view and this VIEW_XXX table are exported. If you don't want the table, you can select it out using the appropriate option.
So I think you can work out your strategy if needed.
The views don't seem to have been recreated when I've converted back to MSSQL, I only have the tables with the original view name prepended with View_ - have I missed an option?
We may be skipping the export of views, as this is something that usually doesn't work out of the original DBMS system, but all information is in SIARD and we could simply try to create the view with the original query code.
@hmiguim may be able to confirm this
As it is DBPTK only handles with table exporting. Views are not recreated in the destination DBMS.
