AI Prompts Library

Generate the appropriate JSON-LD structured data for the following page:

Page type: [Article / Product / FAQPage / HowTo / Recipe / LocalBusiness / Event / Organization]
Page URL: [URL]
Key details:
[LIST RELEVANT FIELDS]

Return a single JSON-LD block ready to drop into a `<script type="application/ld+json">` tag. Use the latest schema.org vocabulary. Include all recommended fields, not just required ones. Validate that the JSON is syntactically correct and that all enums use the official spec values.

You are an expert database architect. Design a normalized, performant database schema based on the application requirements below.

**Application:** [DESCRIBE_YOUR_APPLICATION]
**Database Engine:** [PostgreSQL/MySQL/SQLite/MongoDB]
**Expected Scale:** [Number of users, records, transactions per day]
**Key Requirements:** [LIST_MAIN_FEATURES]

**Your schema design must include:**

1. **Entity-Relationship Diagram** (describe in text format):
   - All entities with their attributes and types
   - Primary keys, foreign keys, and unique constraints
   - Relationship types (1:1, 1:N, M:N) with cardinality
   - Junction tables for M:N relationships

2. **Table Definitions** (SQL CREATE statements):
   - Proper data types (VARCHAR lengths, DECIMAL precision, ENUM values)
   - NOT NULL constraints where appropriate
   - DEFAULT values (timestamps, UUIDs, boolean flags)
   - CHECK constraints for data validation
   - Proper indexing strategy (B-tree, GIN, GiST where appropriate)
   - Composite indexes for common query patterns
   - Partial indexes for filtered queries

3. **Normalization Analysis**:
   - Confirm the schema is at least in 3NF
   - Document any intentional denormalization with justification
   - Identify potential data anomalies and how they are prevented

4. **Performance Considerations**:
   - Index recommendations based on expected query patterns
   - Partitioning strategy if tables will exceed 10M rows
   - Materialized views for complex reporting queries
   - Connection pooling and caching recommendations

5. **Migration Script**: A versioned migration script (using a tool like Alembic, Flyway, or Prisma) that creates the schema from scratch.

6. **Seed Data**: Sample INSERT statements with realistic test data for development.

7. **Common Queries**: Write the 5 most common queries the application will need, with EXPLAIN analysis notes.

You are a TypeScript expert. Given a JSON sample (API response, config file, or data structure), generate comprehensive TypeScript type definitions.

**JSON Input:**
```json
[PASTE YOUR JSON HERE]
```

**Context:** [Is this an API response? Config file? Database record? Describe the data.]

**Generation Rules:**

1. **Type Inference:**
   - Analyze all values to determine the most specific type
   - Detect nullable fields (present but null in the sample)
   - Identify optional fields (might not always be present)
   - Recognize enum-like values (status: "active" | "inactive" | "pending")
   - Detect date strings and type them as `string` with JSDoc annotation
   - Handle arrays: determine if homogeneous or tuple

2. **Naming Conventions:**
   - PascalCase for interface/type names
   - camelCase for properties
   - Descriptive names based on the data context
   - Suffix with Response, Request, Config, etc. as appropriate

3. **Output Format:**
   - Use `interface` for object shapes (extendable)
   - Use `type` for unions, intersections, and utility types
   - Export all types
   - Add JSDoc comments explaining each field
   - Group related types in a logical order
   - Create a namespace or module if there are many types

4. **Additional Types:**
   - Generate a Zod schema that matches the TypeScript types (for runtime validation)
   - Create Pick/Omit utility types for common subsets (e.g., CreateInput = Omit<User, 'id' | 'createdAt'>)
   - Generate a mock data factory function for testing

5. **Edge Cases:**
   - Handle deeply nested objects by creating separate interfaces
   - Handle polymorphic arrays with discriminated unions
   - Add index signatures for dynamic keys
   - Handle BigInt, Date, and other special types

**Output**: Complete .d.ts or .ts file with all types, Zod schemas, and mock factory.

Design database schema for [APPLICATION]:

**Naming Conventions**:
- Tables: plural, snake_case (users, order_items)
- Columns: singular, snake_case (user_id, created_at)
- Primary keys: id (integer, auto-increment)
- Foreign keys: [table_singular]_id

**Standard Columns** (all tables):
- id: Primary key
- created_at: Timestamp
- updated_at: Timestamp
- deleted_at: Soft deletes (optional)

**Relationships**:
- One-to-Many: Foreign key in child table
- Many-to-Many: Junction table
- One-to-One: Foreign key with UNIQUE constraint

**Indexes**:
- Primary key (automatic)
- Foreign keys
- Frequently queried columns
- Composite indexes for multi-column queries

**Data Types**:
- Use appropriate sizes (VARCHAR vs TEXT)
- ENUM for fixed options
- JSON for flexible data (use sparingly)
- UUID for distributed systems

**Constraints**:
- NOT NULL where appropriate
- UNIQUE for natural keys
- CHECK for validation
- DEFAULT values

**Normalization**:
- 3NF for OLTP
- Denormalize for read-heavy (with care)
- Avoid EAV anti-pattern

**Example Schema**:
```sql
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_users_email ON users(email);
```