The following options and parameters are available for creating and configuring tables in Snowflake projects.
Snowflake table types
In Snowflake, tables can be created as permanent, transient, and temporary, affecting their data-retention properties.
Permanent — this is the default table type. Permanent tables always ensure seven days of fail-safe storage. Time travel is enabled by default but can be configured from a minimum of zero to a maximum of one or ninety days.
Transient — behave just like permanent tables but do not have a fail-safe backup
Temporary — exist only for the duration of the session in which they were created. Because they do not persist past the session, temporary tables are not supported in SqlDBM.
Snowflake table properties
Naming and case-sensitivity
All SqlDBM objects must have a unique physical name (in physical project types), taking the schema into account. The logical name is used for metadata and descriptive purposes.
As Snowflake uses case-sensitive naming through double quotes or otherwise defaults to uppercase, the "Use quotes" property is available for table, column, and schema names on Snowflake tables.
To mark a table or column name as case-sensitive, tick the "Use quotes" property next to it.
Where selected, double quotes will be included in the DDL in Forward Engineering.
Options
Transient
Mark "Transient" to identify the table as transient. Transient tables are specifically designed for data that needs to be maintained beyond each session (in contrast to temporary tables) but do not need the same level of data protection and recovery provided by permanent tables.
See more https://docs.snowflake.com/en/user-guide/tables-temp-transient.html
Data Retention Time (Days):
When data in a table is modified, including deletion of data or dropping an object containing data, Snowflake preserves the state of the data before the update. The data retention period specifies the number of days for which this historical data is preserved. Therefore, Time Travel operations (SELECT, CREATE … CLONE, UNDROP) can be performed on the data.
See more https://docs.snowflake.com/en/user-guide/data-time-travel.html
File Format
Specifies the file format in which data can be unloaded from this table.
See more https://docs.snowflake.com/en/sql-reference/sql/create-file-format.html
Column templates
Select a column template to apply its columns to the table. Multiple templates can be added. Columns added via a template can only be edited within the template itself.
Visibility
Affects the table's visibility in:
Different view modes
Import to the Logical Project
DDL generated during forward engineering (FE)
Refer to the table below to understand how the selected visibility settings affect the table. Visibility can also be assigned at the column level; table-level visibility takes precedence in case of a conflict.
Visibility |
View in (view mode) |
Included in Logical Project Import |
Generated in Forward Engineering (FE) |
Physical & Logical |
All |
Yes |
Yes |
Logical only |
Logical |
Yes |
No |
Physical only |
Physical, Pk/Ak, Key |
No |
Yes |
Post script
Include an ad-hoc SQL statement to be generated after the create script in Forward Engineering.
Additional properties
SqlDBM accepts Snowflake policy assignments parsed through DDL/RE. These policies are saved as part of the table definition and will be preserved on FE. In this panel, users can view existing policy assignments or delete existing policy assignments. However, editing or modifying the policy can only be done through the RE process.
These policies apply to all database objects that support them (i.e., tables, views, dynamic tables, etc). They are applied at the object and column levels.
Currently supported policies include the following:
Object level
- Row access policy
- Aggregation policy
- Join policy
Column level
- Masking policy
- Projection policy