Forum Discussion
Advocate IVMultiple Table shortcuts per single lakehouse schema
Can someone please explain the rational for having more than one Lakehouse shortcut per each source?
Currently, multiple shortcuts can be created for the same source table within the same schema, leading to redundancy and potential inconsistencies in data access and lineage tracking.
hi YevgenyM , having multiple Lakehouse shortcuts to the same source table can be intentional in a few cases, for instance, to isolate access for different teams or workspaces (least-privilege via object-level security), expose different subsets/paths (e.g., curated folder vs. raw Delta path), support environment separation (dev/test/prod snapshots), enable versioning or schema transitions (old vs. new layout during migration), and other.
But I agree with you that, if unjustifified/unmanaged duplicates can create redundancy and lineage confusion! Hence, the preference should be a single shortcut plus managed views, enforce (if possible) naming conventions, and apply policies (who can create shortcuts or when they’re retired) to keep access consistent and traceable.
Hope you find this point of view valuable, if so, a kudos would be nice and if this is solution to your question, mark as so! All the best
4 Replies
- svenchio
Super User
hi YevgenyM , having multiple Lakehouse shortcuts to the same source table can be intentional in a few cases, for instance, to isolate access for different teams or workspaces (least-privilege via object-level security), expose different subsets/paths (e.g., curated folder vs. raw Delta path), support environment separation (dev/test/prod snapshots), enable versioning or schema transitions (old vs. new layout during migration), and other.
But I agree with you that, if unjustifified/unmanaged duplicates can create redundancy and lineage confusion! Hence, the preference should be a single shortcut plus managed views, enforce (if possible) naming conventions, and apply policies (who can create shortcuts or when they’re retired) to keep access consistent and traceable.
Hope you find this point of view valuable, if so, a kudos would be nice and if this is solution to your question, mark as so! All the best
- stoic-harsh
Hi YevgenyM,
Adding to svenchio's points, think of shortcuts as references, not copies. This flexibility (as we all know) allows the same data to be configured differently (for example, CLS, or RLS) as per the end-users (Finance, Ops, Analytics). I agree that multiple shortcuts referencing the same source within a schema can be confusing, but given that their names would be unique (each table should have unique name in the same schema), I would call it a governance and naming concern rather than a design flaw.
Would love to hear your thoughts. I find it quite interesting to think about shortcuts from this angle.
Hi YevgenyM,
I would also take a moment to thank svenchio , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Regards,
Community Support Team.Hi YevgenyM,
I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.
Regards,
Community Support Team.
