Key benefits of virtual data tables

Dear ONE DATA experts,
I’m keen to know what 2-3 key benefits do you see, to have virtual data tables?

Thanks
Martin

You can take a look at the answer here: Do VDTs have performance benefits? - #4 by adrian.berndl

  • being able to maintain a complex SQL query or Apps data source definition in one spot rather than several: instead of writing multiple Apps data sources with more or less the same complex content you write only one in the definition of the virtual data table
  • being able to create views on data tables that can be used in workflows: This may save you quite some query processors
  • in combination with resource sharing and access rights management in ONE DATA the possibility to construct something like a “more powerful analysis authorization”: You can create a virtual data table that has the same content as the underlying data table but without certain rows or columns. You can ensure that a user of the virtual data table cannot see this data. You can combine this with the usual analysis authorization of the underlying data table.
1 Like

The info from Katharina is actually quite crucial. There is nothing in the concept of virtual data tables that gives you any guaranteed performance benefit.

Something that I think Jonas mentioned: VDTs are - by construction - immutable, so you can expose them without fearing that the data gets modified

3 Likes

To my knowledge VDTs are the only way to share data without creating a data replication or the ‘general sharing risk’.
That is the risk that the shared data is changed (e.g. schema) or even deleted in the target project (and hence also in the home project…).
The rights in the target project can change, e.g. if you share the DT to a certain project, no user there has delete rights in this project but later they receive these rights and could delete it without knowledge of the original sharer.

Of course the users in the target project can then only read the data and not write to it.

It’s important to mention that if the users in the target project have the rights to delete, they can of course also delete the VDT, hence if you want to share the same data to multiple projects, you should always make a new VDT (a project specific VDT). Because if you would create a VDT of Table A and share the same VDT to Project X,Y, Z and e.g. someone deletes the VDT in one project, it’s of course also deleted in every other project. Basically the same problem why you do not directly want to share tables in the first place.

Sidenote:
Unfortunately you cannot ‘lock’ the VDT definition, e.g. only select certain columns/rows to create a VDT and then share it to a project, without anyone in the target project being able to touch the VDT definition.

Hence I always leave the default SQL statement (or even remove the “sql” from the dataOptions, which might give you a performance boost in loading as I have learned from @stefan.ganser ), because it’s usually always possible that users in the project where you share the VDT can edit the VDT definition anyways.

1 Like

Thanks to all your valuable input. that helps me a lot in positioning against other vendors.