Appearance
Examples
This page provides real-world schema examples demonstrating DDK capabilities using operational physical world scenarios.
Table of Contents
Rail Network Operations
This example demonstrates managing a rail transit network with real-time service tracking and disruption management.
Domain Problem
Rail operators need to track train services across multiple lines and stations, monitor service delays, manage disruptions, and communicate impacts to passengers in real-time.
Key Entities and Relationships
- Lines and Stations: Many-to-many relationship allowing stations to serve multiple lines and lines to serve multiple stations, with ordering information preserved
- Services: Individual train services running on a line, with scheduled times, current status, and delay tracking
- Service Stops: Granular tracking of scheduled and actual arrival/departure times at each station
- Disruptions: Incident tracking with severity levels that can affect multiple services, using many-to-many relationships to model cascading impacts
Capabilities Demonstrated
- Complex many-to-many relationships between lines and stations with join table attributes
- Back references for bi-directional navigation
- Enum constraints for status and severity fields
- Default values for operational states
- Custom resolvers for querying active disruptions, calculating impact metrics, and filtering delayed services
- Real-time subscriptions for disruption updates and service status changes
Benefits to Users
- Real-time visibility into service delays and disruptions across the network
- Automated impact analysis showing affected services and passenger counts
- Historical tracking of scheduled vs actual service performance
- Efficient querying of disruptions by severity, line, or time period
Asset Maintenance
This example demonstrates managing physical asset lifecycle, preventive maintenance schedules, and work order execution across distributed sites.
Domain Problem
Organizations with distributed physical infrastructure need to track asset condition, schedule preventive maintenance, respond to emergencies, assign qualified technicians, and maintain compliance with maintenance intervals.
Key Entities and Relationships
- Sites and Assets: Physical locations containing equipment, with geolocation support for field operations
- Asset Types: Template definitions with default maintenance intervals that cascade to individual assets
- Work Orders: Maintenance tasks with type classification (preventive, corrective, inspection, emergency) and priority levels
- Technicians and Assignments: Skill-based resource allocation through many-to-many work order assignments
- Maintenance Tracking: Automatic calculation of next maintenance due dates based on asset type defaults and last service
Capabilities Demonstrated
- Check constraints ensuring positive maintenance intervals
- Default status values for operational states
- Unique constraints on serial numbers and employee IDs
- One-to-many relationships for asset hierarchies
- Many-to-many join tables for technician assignments with timestamp attributes
- Custom resolvers for identifying overdue assets and finding available qualified technicians
- Priority-based work order filtering
Benefits to Users
- Proactive identification of overdue maintenance before equipment failures
- Skill-based technician assignment ensuring qualified resources handle specialized equipment
- Historical maintenance records for compliance reporting and asset lifecycle analysis
- Priority-driven work order queues for efficient resource allocation
- Real-time notifications when critical work orders are created
Fleet & Logistics
This example demonstrates managing vehicle fleets, delivery routes, driver assignments, and real-time tracking across multiple depots.
Domain Problem
Logistics operators need to coordinate vehicles, drivers, and delivery routes efficiently while respecting vehicle capacity constraints, driver licensing requirements, delivery time windows, and depot capacities.
Key Entities and Relationships
- Depots: Distribution centers with capacity constraints and geolocation, serving as home bases for vehicles and drivers
- Vehicles and Drivers: Resources with availability status, licensing, and capacity attributes that must be matched to appropriate routes
- Routes and Stops: Pre-defined delivery paths with ordered stops, service time windows, and distance/duration estimates
- Route Assignments: Daily allocation of vehicle and driver pairs to routes, tracking departure and completion times
- Deliveries: Individual consignments linked to both route assignments and specific stops, with weight validation and proof-of-delivery tracking
Capabilities Demonstrated
- Check constraints enforcing positive capacity and weight values
- Geolocation attributes for depots, vehicles, and route stops enabling map-based tracking
- Complex hierarchical relationships linking routes through assignments to deliveries
- Ordered sequences for route stops ensuring correct delivery order
- Service window constraints for time-sensitive deliveries
- Custom resolvers for resource availability queries, utilization metrics, and assignment optimization
- Real-time subscriptions for route status updates
Benefits to Users
- Intelligent resource matching ensuring vehicles have sufficient capacity and drivers have appropriate licenses
- Utilization analytics showing fleet efficiency and identifying underused assets
- Real-time visibility into route progress and delivery completion
- Historical delivery performance data for route optimization
- Capacity planning support through depot and vehicle constraint validation
- Proof-of-delivery tracking with signature capture
Pattern Examples from Test Suite
The DDK test suite contains 30+ schema examples demonstrating specific features and patterns.
Self-Referencing Many-to-Many
Demonstrates self-referencing relationships where entities relate to other entities of the same type. The classic example is a social network where people have friends who are also people, using a join table to track the bidirectional relationships.
Capabilities: Self-referential many-to-many mappings, symmetric relationship modeling, join table patterns for same-type associations.
Primitive Arrays
Demonstrates native database array support for fields that store multiple primitive values. Users can have arrays of favorite numbers or two-dimensional arrays for grid data like game boards, stored efficiently as native database array columns.
Capabilities: Custom scalar types for 1D and 2D arrays (Int, String, Float, Bool), efficient storage without junction tables, support for array operations at the database level.
Available types: Int1DArray, String1DArray, Float1DArray, Bool1DArray, Int2DArray, String2DArray, Float2DArray, Bool2DArray.
Check Constraints
Demonstrates database-level validation rules that ensure data integrity. Common patterns include validating that age is positive, email addresses match a format, or numeric values fall within acceptable ranges.
Capabilities: SQL check constraints defined in schema, validation enforced at database level, prevention of invalid data at write time.
Multiple Constraints
Demonstrates combining multiple constraint directives on a single field to enforce complex validation rules. Fields can be simultaneously unique, non-null, and have default values, with all constraints enforced by the database.
Capabilities: Constraint composition, combining primary keys with uniqueness, default values with non-null constraints, layered validation strategies.
Custom Resolvers
Demonstrates extending auto-generated CRUD operations with custom business logic. The two-file pattern separates ORM definitions (database schema) from custom resolvers (application logic), supporting queries with complex filtering, mutations with business rules, and real-time subscriptions.
Capabilities: Custom query resolvers for complex lookups, custom mutations for business logic, subscription endpoints for real-time updates, separation of schema and resolver concerns.
Back References
Demonstrates bidirectional relationship navigation. A user has many contacts (one-to-many), and each contact can navigate back to its owning user using a back reference, enabling efficient queries in both directions without duplicating relationship data.
Capabilities: Bidirectional relationship traversal, back reference mappings, efficient queries from child to parent, avoiding N+1 query problems.
Related Documentation
- Schema Guide - Detailed directive reference
- Custom Resolvers - Implementation guide
- Architecture - How the DDK works
- Usage - How to use the DDK service
- FAQs - Common questions