# 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: 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:

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

The question should be specific, self-contained, and written in natural language.
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.