This message was deleted.
# secoda-support
w
This message was deleted.
e
A business plan is not required. We are able to generate the ERDs off of foreign and primary keys. Do you know if those keys are defined for your database? If so it’s an issue on our end that we’ll have to look into
a
Ah, I don't believe we have fk's defined in the db - without these is it not possible to manually generate?
e
It’s not currently, but that’s a good idea for a future feature. Would you find it useful to manually specify which columns are related to each other?
a
very much so!!!
p
@elegant-house-93198 What about dbt’s relationship tests? PKs and FKs are not universally supported by all data warehouses, and their definition,enforcement and utility varies greatly across platforms. off the top of my head, i know Redshift and snowflake don’t enforce referential integrity. not sure about BQ. I can use them in Postgres, but I’m just building up technical debt for my future self when I need to ugprade to a true DW
I am using dbt-metabase to carry those relations from dbt to Metabase…would be great to see simialr functionality here
e
That’s a good question @polite-microphone-78573, we only use PKs and FKs for relationship databases like Postgres, MySQL, Oracle, MS SQL which do support them. For data warehouses like Redshift, BigQuery, and Snowflake we use query parsing. dbt provides a lot of the information in their metadata that gives context on the relationships between columns and tables, so we would use that for understanding what column a test is running against. Does that make sense?