Database Design Starts with Relationships
What Culina's food catalog and Elysion's operational records reveal about modeling data beyond a single screen.
A recipe is more than a document
In Culina, ingredients are independent records with categories, nutrition information and allergen relationships. A recipe connects ingredients through quantities, units and groups, with ordered preparation steps alongside them.
That structure supports questions which would be awkward if the recipe were only formatted text: which recipes use an ingredient, what information belongs to that ingredient, and how should a grouped ingredient list be presented?
It also places responsibility on the relationship. A quantity belongs to an ingredient’s use in a recipe, not to the ingredient in isolation. The recipe supplies context that the catalog record cannot carry by itself.
Model the connection explicitly
The following is a conceptual view of Culina’s domain, not an exact database schema:
Recipe
→ ingredient groups
→ ingredient + quantity + unit
→ ordered preparation steps
Ingredient
→ category
→ nutrition information
→ allergen relationships
Cookbook → recipes
Separating these concepts gives the same information a role in authoring, discovery and personal collections. PostgreSQL and Entity Framework Core implement the persistence layer, but the important modeling work precedes the ORM mapping: deciding what each record means and which relationships carry their own context.
Business workflows add history and ownership
Elysion applies relational modeling to funeral operations. Orders connect customers, deceased-person records, ceremonies, items and documents. Cemetery records cover grave sites, ownership and interments. Inventory distinguishes movements, reservations and transfers.
Documents add a temporal relationship: a generated file remains associated with its source record and template version. Knowing which template produced a document is different from knowing which template is current now. Preserving that association gives later investigation a concrete starting point.
Multi-tenancy adds another dimension. Tenant locations, users, permissions, subscriptions and entitlements describe different aspects of ownership and access. Treating them as one undifferentiated tenant flag would conceal those distinctions.
Keep the model grounded in current behavior
Culina’s meal planning, pantry and shopping-list ideas remain roadmap work. The existing food model can support future exploration, but it does not justify claiming those workflows already exist.
A useful relational model serves the questions the product asks today while preserving the meaning of its records. The goal is a coherent account of ingredients, orders or documents that survives beyond the first screen built around them.
