> For the complete documentation index, see [llms.txt](https://docs.syntho.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syntho.ai/setup-workspaces/create-a-workspace/use-sql-views-as-input-tables.md).

# Use SQL views as input tables

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.

{% hint style="info" %}
Syntho can read from a **table or view** in the source. See [Table view](/configure-a-data-generation-job/configure-table-settings.md).
{% endhint %}

#### Example (PostgreSQL): flatten customers + last order

```sql
CREATE OR REPLACE VIEW syntho_customer_entity_v AS
SELECT
  c.customer_id,
  c.country_code,
  c.segment,
  c.signup_date,
  o.order_date  AS last_order_date,
  o.order_total AS last_order_total
FROM customers c
LEFT JOIN LATERAL (
  SELECT order_date, order_total
  FROM orders o
  WHERE o.customer_id = c.customer_id
  ORDER BY order_date DESC
  LIMIT 1
) o ON true;
```

### 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](/configure-a-data-generation-job/configure-column-settings/ai-powered-generation.md).
* Keep the generator config small. Prefer calculated columns for only the rules you must enforce.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.syntho.ai/setup-workspaces/create-a-workspace/use-sql-views-as-input-tables.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.