Fix em-dashes and expand pre-aggregates section

Generated-By: mintlify-agent

Author: mintlify[bot]

guides/developer/dbt-model-best-practices.mdx

@@ -10,14 +10,14 @@ When building your dbt models for Lightdash, following these best practices will
 
 When deciding between wide materialized tables and smaller normalized tables that require multiple joins, you're balancing trade-offs across three dimensions: **performance**, **self-serve usability**, and **analytical depth**.
 
-There's no one-size-fits-all answer—the right approach depends on your team's needs and how you want to empower your users.
+There's no one-size-fits-all answer. The right approach depends on your team's needs and how you want to empower your users.
 
 ### Wide tables vs. multi-join models
 
 | Factor | Wide tables | Multi-join models |
 |--------|-------------|-------------------|
-| **Performance** | Generally faster—materialized at the grain you need for specific analyses | Joins computed at query time; mitigated by fanout protection |
-| **Self-serve usability** | Easier for business users—all fields in one place, less overwhelming | Can be intimidating—10 joined tables on one page is a lot for most users |
+| **Performance** | Generally faster since they're materialized at the grain you need for specific analyses | Joins computed at query time, though mitigated by fanout protection |
+| **Self-serve usability** | Easier for business users with all fields in one place, less overwhelming | Can be intimidating since 10 joined tables on one page is a lot for most users |
 | **Analytical depth** | May require multiple wide tables for different use cases | More flexible for complex analyses across multiple dimensions |
 
 ### When wide tables work best
@@ -37,7 +37,7 @@ Modern columnar data warehouses (like Snowflake, BigQuery, and Redshift) are opt
 
 Some analyses genuinely require multiple joins. For example, analyzing Bookings while filtering by an upstream dimension (like organic SEO traffic source) and breaking down by a downstream dimension (like a specific location) will likely require joins to be correct.
 
-Lightdash handles multi-join explores well technically—[fanout protection](/references/joins#many-to-many-or-one-to-many-with-fanout-protection) ensures accuracy. However, looking at a page with many joined tables can be overwhelming for business users who aren't familiar with the data model.
+Lightdash handles multi-join explores well technically, and [fanout protection](/references/joins#many-to-many-or-one-to-many-with-fanout-protection) ensures accuracy. However, looking at a page with many joined tables can be overwhelming for business users who aren't familiar with the data model.
 
 ### Common approaches
 
@@ -161,7 +161,11 @@ Pre-aggregates are especially useful for:
 - Commonly used metric combinations
 - Time-series data at standard intervals (daily, weekly, monthly)
 
-The trade-off is maintenance overhead—you need to keep pre-aggregates in sync with your source data and ensure users understand when to use them vs. the detailed tables.
+You can implement pre-aggregates in two ways:
+- **In Lightdash**: Use [Lightdash pre-aggregates](/references/pre-aggregates) to automatically cache aggregated results
+- **In dbt or your warehouse**: Pre-join and materialize tables directly as dbt models or warehouse tables if you prefer to manage them outside of Lightdash
+
+The trade-off is maintenance overhead. You need to keep pre-aggregates in sync with your source data and ensure users understand when to use them vs. the detailed tables.
 
 ### Leverage caching