AnyDB: Object-based Business Database

Introduction

Most business software forces you to fit your operations into rigid tables, modules, and forms. Real work doesn’t look like that. A factory has regions and production lines. A vendor has contracts, contacts, invoices, and certifications. A vehicle has an engine, wheels, and maintenance history. These things belong together, not scattered across spreadsheets or separate tools.

AnyDB takes a different approach. Instead of storing your information in disconnected tables, AnyDB lets you build your business the way it actually works: as objects that naturally contain other objects and stay linked together.

This means you can model your operations the same way you think about them:

• A project that has tasks, files, and approvals
• A vendor that has contracts, contacts, and purchase orders
• A product that has components, inspections, and photos

Nothing is forced into tables. Nothing requires joins or rebuilding schema.
You simply create the objects you need and connect them.

This page explains how AnyDB’s object-based model works and why it’s a more natural fit for real-world operations than traditional relational databases.

Watch a Video Overview

Watch a key concepts overview video here: Key Concepts

Relational Databases: Tables For Everything

With a traditional relational database, you model a car like this:

• Cars table
• Engines table
• Frames table
• Wheels table

Each table holds rows of one type. Relationships are managed with foreign keys.

To assemble Car #1, you have to:

1. Look up the car row in Cars
2. Join Engines on engine_id
3. Join Frames on frame_id
4. Join Wheels on car_id (possibly four wheel rows)

You get the full car only by joining multiple tables together. The data model is fragmented:

• A simple change (new wheel type or engine version) can require schema changes or new tables.
• Adding non-tabular content like documents or notes often means bolting on extra systems.
• Every Record has to be exactly the same structure. You can't have one car with additional attached data.
• Real world entities like "Factory", "Project", or "Vendor" end up scattered across tables, files, and tools.

Relational databases are great for highly structured, repetitive transactions. They are much less natural for dynamic operational data.

---

AnyDB: Object-Based Data Model

AnyDB models the world as objects that can contain other objects.

Using the car example:

• A Car is an object.
• Engine, Frame, and each Wheel are objects.
• The Car object has direct links to its Engine object, Frame object, and four Wheel objects.

You do not need separate tables and joins to assemble the car.
You open Car #1 and you see:

• Car overview fields
• Linked Engine object
• Linked Frame object
• Linked Wheel objects
• Any files, photos, and notes attached to each of those objects

Each object can have:

• Its own fields and layout
• Its own history and comments
• Its own attached files
• Its own relationships to other objects

Attaching Objects in AnyDB

In AnyDB, you don’t assemble data by joining separate tables. Instead, you build richer objects by attaching related objects to them.

Using the visual:

• The Car is the main object.
• A Frame object, Engine object, and multiple Wheel objects are simply attached to it.
• Each attached part is a full object with its own fields, files, and relationships.

This makes the Car a complete, self-contained object that naturally includes everything related to it.
No foreign keys, no table joins, no scattered data — just connected objects that reflect how things exist in the real world.

---

From Cars To Real Business Data

The same idea applies to business records.

• A Company record can link to:
  • Contact records
  • Deals records
  • Call Log records
  • Invoice records
  • File records (contracts, registration docs, etc.)

Each of these is a first class object. You can open it, attach files, see its own relationships, and reuse it in many contexts.

---

Building Hierarchies And Networks

With an object-based model you can grow the structure without redesigning tables.

For example

• Global object
  • linked to Region objects (North America, Europe, Asia)
    • each linked to Factory objects
      • each factory linked to many Car objects

You can also attach one object to many contexts:

• One Car object can be linked to:
  • A Factory object
  • A Luxury tier object
  • A Sedans category object

Same car. Different contexts. No new tables required.

---

Why This Is Different From Relational Databases

Relational databases	AnyDB object-based model
Data is split across many fixed tables	Data is captured as complete, self-contained objects
Relationships rely on foreign keys and joins	Relationships are direct object to object links
Schema changes require migrations and careful planning	Objects evolve by adjusting templates and fields
Hard to mix data with files, notes, and checklists	Objects naturally hold fields, files, comments, and sub-objects
Built for transactional accounting workloads	Built for real operational records and workflows

The key shift:
In a relational system you ask, “Which tables do I need to join?”
In AnyDB you ask, “Which objects are connected to this object?”

---

Why the Object Model Matters

• More intuitive than relational models
  You think in terms of objects and real world items: Car, Engine, Vendor, Project and not tables.

• Non-developers can build confidently
  No need to understand joins or schema design. Attaching objects feels natural.

• Model complex systems quickly
  Factories, regions, products, shipments, all can be represented as linked objects.

• Easy to extend and expand
  Add new fields, attach new objects, or reshape the model without breaking anything.

• Multiple views on the same object
  A single object can appear in dashboards, lists, timelines, or galleries.

• Objects can be worked on independently
  Each object has its own fields, files, activity, and history.

• Objects can reference each other in formulas
  A Car can pull values from its Engine or Wheels through formulas without joins.

This is why AnyDB’s model aligns far better with how real businesses operate.