The short answer: open DataGrip, position your cursor in a SQL comment block, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak your query explanation for 60-90 seconds, and AICHE inserts detailed documentation.

DataGrip users write complex SQL queries and database migrations requiring detailed comments explaining join logic and performance considerations, typing takes 10+ minutes per query. Voice captures database reasoning faster than keyboard mechanics.

Open DataGrip with your database connection.
Create or open a SQL file.
Position your cursor where you need documentation (above query or in comment block).
Press your AICHE hotkey to start recording.
Speak your complete explanation.
Press the hotkey again-AICHE transcribes and inserts the text.
Add SQL comment markers (-- or /* */) manually.

Query Documentation

Complex Join Explanations

Position cursor above complex queries and dictate complete logic. Example: "Document this complex SQL query for quarterly sales report. Query joins five tables including orders, order items, products, customers, and sales regions. Main query selects customer name, region, product category, total order count, and revenue sum. Uses LEFT JOIN to include customers with no orders in period. Filters for orders between specific quarter dates using date range on created_at timestamp. Groups by customer id, region id, and product category. Includes HAVING clause to show only customers with revenue exceeding 10000 dollars. Orders results by revenue descending. Uses window function to calculate running total and percentage of regional revenue. Includes indexes on created_at, customer_id, and region_id for performance. Explain why we use LEFT JOIN instead of INNER JOIN for customer retention analysis and note the performance impact of window functions on large datasets."

The complete query explanation flows naturally when spoken, documenting join strategy and performance trade-offs.

Migration Documentation

For schema changes, dictate migration rationale. Example: "Explain this database migration adding audit logging. Migration creates new table audit_log with columns for id as auto-increment primary key, table_name as varchar 50 storing affected table, record_id as bigint referencing modified record, action as enum with INSERT UPDATE DELETE options, user_id as foreign key to users table, changes as JSONB storing before and after values, and timestamp as datetime defaulting to current time. Adds triggers on users, orders, and products tables capturing all modifications. Index on table_name and timestamp for efficient querying by date range. Index on user_id for auditing specific user actions. JSONB column allows flexible change tracking without schema modifications. Trade-off: 15% write performance overhead acceptable for compliance requirements. Retention policy: archive records older than 2 years to audit_log_archive table maintaining query performance. Migration reversible with down script dropping triggers and table."

Speaking migration context documents decisions for future maintainers.

Performance Optimization

Query Tuning Documentation

When optimizing slow queries, dictate the analysis. Example: "Document query optimization for user search feature. Original query performs sequential scan on users table with 5 million records taking 12 seconds. Problem: WHERE clause uses LOWER function on email column preventing index usage. Solution one: create functional index on LOWER email allowing index scan reducing query time to 80 milliseconds. Solution two: add generated column storing lowercase email with regular index providing same performance without functional index complexity. Choose solution two for better PostgreSQL version compatibility. Additional optimization: add composite index on status and created_at columns for filtered queries on active users created in date range. EXPLAIN ANALYZE shows index scan with 99.8% reduction in rows examined. Monitor query performance using pg_stat_statements showing average execution time under 100 milliseconds after optimization."

Performance optimization rationale becomes searchable documentation.

Index Strategy Documentation

For database schemas, explain indexing decisions. Example: "Document indexing strategy for e-commerce database. Orders table with 50 million records requires careful index design. Primary index on order_id as clustered index. Secondary index on customer_id for user order history queries averaging 1000 orders per customer. Composite index on status and created_at for admin dashboard showing recent pending orders. Partial index on payment_method WHERE status equals failed for payment retry analysis excluding 95% of successful orders. No index on notes field containing free-text avoiding index bloat on low-cardinality unstructured data. Trade-offs: six indexes consume 8GB storage but reduce average query time from 3 seconds to 150 milliseconds. Index maintenance during peak hours causes 5% write slowdown acceptable given read-heavy workload. Quarterly index rebuild during maintenance window prevents fragmentation."

Index strategy documentation guides schema evolution decisions.

Schema Design

Table Relationship Documentation

For complex schemas, dictate relationship explanations. Example: "Explain database schema for multi-tenant SaaS application. Tenants table stores organization data with tenant_id as primary key. Users table links to tenants via tenant_id foreign key with ON DELETE CASCADE ensuring orphaned users removed. Organizations table uses UUID primary keys for security preventing tenant ID enumeration. Subscriptions table tracks billing with one-to-one relationship to tenants using UNIQUE constraint on tenant_id. Audit trail uses tenant_id as partition key allowing per-tenant data isolation. Row-level security policies filter queries by current_tenant_id session variable enforcing data isolation at database level. Foreign key constraints use DEFERRABLE INITIALLY DEFERRED for transaction integrity during bulk operations. Indexes on tenant_id columns across all tables enable efficient tenant data queries."

Schema design documentation becomes onboarding material for new engineers.

Result: SQL query explanations with join rationale, migration documentation with rollback procedures, and performance optimization analysis that took 18 minutes to type now take 5 minutes to dictate, and database work becomes more documented because speaking technical database concepts is faster than typing SQL comment blocks.

Do this now: open DataGrip, write or open a complex SQL query joining multiple tables, position cursor above it, press your hotkey, and spend 90 seconds explaining the query logic, join types, filtering strategy, and performance considerations as if teaching someone new to the schema.

AICHE +DDatagrip Integration