page239
326
For internal use cases, you may choose to distribute unentitled data to trusted
internal consumers where their local entitlement overlays may apply. This distinction is
important: internal data product distribution use cases are much simpler to implement
and easier to gain approval for than external data product distribution use cases.
Filter Engine
The absence of client object mapping precludes the use of SQL statements for generating
client-specific objects. SQL statements act as overlays to the underlying data product
objects that incorporate all client-specific filters and masks.
The previous statement is a bit of a mouthful to say and sounds complicated, and
in truth, generating bespoke objects is an advanced topic. I demonstrate how to do
this later.
Filter engine output should be thoroughly tested before deployment. Only when
confident should you consider automated deployment, along with corresponding
generated test cases.
Client-Specific Shares
Snowflake shares are structural container objects created by the
ACCOUNTADMIN
role.
Share ownership may be transferred to other roles. Note that a single role can hold this
privilege on only a specific share object at a time. Semi-automated client-specific sharing
relies upon the dynamic generation of a share and schema, a Data Definition Language
(DDL) entitlement, and finally assigning the share to a nominated Snowflake account.
When the dynamic requirements have been satisfied, you can deploy the filter
engine output; note that the data content for your objects should differ for each
client. A hybrid approach is to generate a common suite of unentitled objects for bulk
distribution alongside a bespoke defined suite of components. Your use cases will
inform your decision.
Once a share has been authorized to an account, importing the share appears as
a database within the Snowflake user interface. The imported database requires local
client administration to make the generated data products accessible.
Chapter 9
Client expeCtations