Skip to main content

Common Modeling Patterns

This page shows common, proven ways to model real operational systems in AnyDB.

Each pattern follows the same principles:

For attachment:

  • attach objects that should not exist on their own
  • use attachments for structure and aggregation

For Links:

  • link objects that are reusable and independent
  • use links for lookups and reuse

Orders and Line Items​

What you are modeling​

  • orders
  • items within each order
  • reusable products or SKUs
  • Order (object)
    • Order Line (attached)
      • quantity
      • price at time of order
      • status
      • link → Product / SKU

AnyDB Order Line Attachment Example

Why this works​

  • order lines do not exist without an order → attachment
  • products exist independently → link
  • order totals roll up from order lines
  • product details are pulled via lookup (DYNREF)

Common mistake to avoid​

  • reusing the same Product object as an order line
    (this breaks aggregation and lifecycle)

Inventory and Warehouses​

What you are modeling​

  • warehouses
  • physical stock
  • reusable product definitions
  • Warehouse (object)
    • Inventory Record (attached)
      • quantity
      • batch / lot
      • cost
      • link → Product / SKU

AnyDB Warehouse Inventory Example

Why this works​

  • inventory records are physical instances → attachment
  • warehouses aggregate inventory via rollups
  • products remain reusable across warehouses

Alternative (high-scale setups)​

  • Inventory Record as standalone
  • link → Warehouse
  • use views and filters instead of rollups

Choose this only if aggregation at the warehouse level is not required.

Projects and Tasks​

What you are modeling​

  • projects
  • work items inside projects
  • shared resources or people
  • Project (object)
    • Task (attached)
      • status
      • effort
      • due date
      • link → Employee / Resource

AnyDB Project Tasks Example

Why this works​

  • tasks do not exist without a project → attachment
  • project progress rolls up from tasks
  • employees are reused across projects → link

Vendors and Purchase Orders​

What you are modeling​

  • vendors
  • purchase orders
  • line items per order
  • Vendor (object)
  • Purchase Order (attached)
    • PO Line (attached)
      • quantity
      • unit cost
      • link → Product / SKU

AnyDB Vendor PO Example

Why this works​

  • vendors exist independently → top level object
  • POs are per-vendor facts → attachment
  • PO lines are per-order facts → attachment
  • totals roll up cleanly
  • vendor details stay centralized

A simple way to decide​

When connecting things, ask yourself:

  • Does this belong inside something else?
    → attach it
  • Is this something reused or shared?
    → link it

If you follow these rules, your model will stay correct as it scales.

What to remember​

  • Attach things that belong together
  • Link things that are reused
  • Most systems use both

Start simple. You can always add more later.