Use SQL views as input tables

Shape your source data into a single, analysis-ready entity table (often via a SQL view) before configuring Syntho.

Use a SQL view when you need to reshape data before Syntho reads it.

This is most common for:

  • AI synthesize workflows that work best on a single entity table.

  • Data sharing where recipients prefer one clean table.

  • Analytics sandboxes where BI dashboards query a flattened model.

Why this matters

A well-designed input table makes configuration simpler and safer:

  • Fewer joins means fewer linkage points.

  • You can enforce “one row = one entity” rules.

  • You can precompute derived fields once, then keep Syntho configs minimal.

Practical pattern: create a single entity view

  1. Pick the entity you care about (customer, patient, account).

  2. Join only what you need for the use case.

  3. Ensure every row has a stable, unique key.

circle-info

Syntho can read from a table or view in the source. See Table view.

Example (PostgreSQL): flatten customers + last order

Destination considerations

Syntho writes to the destination. The destination object must usually be a table.

If your source is a view:

  • Create a destination table with the same columns.

  • Or write to a filesystem destination (e.g., Parquet), if that fits your workflow.

Edge cases and gotchas

  • Missing primary keys: add a stable surrogate key in the view, or model a different entity.

  • Exploding joins (1-to-many): aggregate first (e.g., counts, sums, “last event”), then join.

  • Materialized views: use them when the view becomes slow to query during training.

  • Security: grant read-only access to the view, not the full underlying schema.

Where to use this in Syntho

  • Use the view as the source table when configuring AI synthesize.

  • Keep the generator config small. Prefer calculated columns for only the rules you must enforce.

Last updated

Was this helpful?