PART 1 - Intro
PART 2 - Making it actually work
PART 3 - Some notes
What I Accidentally Implemented (And Why It Matters)
Here’s the humbling part of this story: when I first built SOOT, I thought I’d invented something completely new. That shower-moment insight felt revolutionary. Then I started researching and realized I’d independently rediscovered union types, polymorphic associations, the adapter pattern, and about half a dozen other computer science concepts that have been around since before I was born.
But here’s the thing that still makes this worthwhile—implementation context matters. Knowing that something is theoretically possible is different from knowing how to build it cleanly within the constraints of a specific tool. The SOOT pattern isn’t innovative computer science, but it might be innovative no-code architecture.
The Academic Concepts (For Context)
If you’ve studied computer science or worked with strongly-typed languages, you’ll recognize these patterns:
Union Types are exactly what SOOT implements—a value that can be one of several types, but exactly one at any given time. In Rust you’d write enum Item { Event(Event), Task(Task), Training(Training) }. In SOOT, that’s your hub table with exactly one lookup filled.
Polymorphism is what happens when you call thisRow.Source.title_ and get the right result regardless of which concrete type you’re dealing with. Same interface, different implementations underneath.
The Adapter Pattern is what those unified fields (title_, dateStart_) actually are—they adapt different interfaces to a common shape. Classic Gang of Four stuff.
Composition over Inheritance is the architectural choice here. Instead of making Event, Task, and Training all inherit from BaseItem (which would be a nightmare to maintain), we compose them through references in the hub table.
The database folks will recognize Polymorphic Associations—one table referencing multiple other tables through foreign keys.
Why This Works Well in Coda (The Technical Analysis)
The reason SOOT works elegantly in Coda isn’t just about the pattern—it’s about how the pattern maps to Coda’s specific strengths.
Coda’s lookup columns are properly indexed and support dot-notation with autocomplete. That means thisRow.Source.title_ is both fast at runtime and pleasant to author. You get IDE-like hints as you type, and Coda catches typos for you.
The formula recalculation engine handles the unified fields efficiently because they’re simple mappings. No table scans, no complex joins—just direct column references that update instantly when source data changes.
The validation system (Valid?/IB) leverages Coda’s conditional formatting and filtering to keep broken data out of user views while preserving it for debugging. This is harder to achieve cleanly in traditional databases.
Performance and Scaling Considerations
Let’s be realistic about where this pattern works well and where it might struggle:
Sweet spot: A few thousand rows across your source tables, with unions that need live updates and full Coda affordances (inline editing, grouping, actions). Perfect for operational dashboards where people need to both view and act on data.
Potential issues: Very large datasets (tens of thousands of rows) might make the unified views sluggish. Cross-doc scenarios add complexity because you lose the direct lookup benefits. Heavy automation can create bottlenecks if you’re not careful about idempotence.
Alternatives to consider: For read-only reporting over large datasets, a virtual union using ListCombine and FormulaMap might be lighter. For scenarios where you can’t touch source schemas, sync packs might be more appropriate despite the latency.
The Honest Assessment
Is SOOT a revolutionary breakthrough? No. Is it useful? Absolutely.
The value isn’t in the novelty of the underlying concepts—it’s in the practical execution within Coda’s constraints and capabilities. Most people who understand union types intellectually couldn’t translate that into a working, maintainable solution in a no-code environment. That translation work has genuine value.
The pattern fills a real gap between what Coda provides natively and what complex docs actually need. It’s good engineering disguised as simple table design.
Community Feedback Welcome
I’ve been using variations of this pattern across multiple docs for months now, but I’m sure there are edge cases and optimizations I haven’t discovered. If you’ve built something similar, found performance issues, or have ideas for improvement, I’d love to hear about it.
Particular areas where I’d welcome critique: cross-doc scaling strategies, permission handling when source tables have different access levels, automation patterns for very high-frequency updates, and alternative approaches to the unified fields design.
The goal isn’t to defend this as the perfect solution—it’s to refine it into something the community can rely on.
Final Thoughts on Naming and Adoption
SOOT (Structured One-Of Table) describes exactly what it is. When someone asks “what’s a SOOT?”, the answer is in the name. Alternative: SUIT (Single Unified Interface Table) if your organization prefers interface-focused language.
Whether this becomes a widely adopted pattern depends on whether it solves real problems for real people. The computer science pedigree is interesting, but the practical utility is what matters. If you’re dealing with union-type problems in Coda, try building a SOOT and see if the development experience feels as clean as it did for me.
Questions I’m curious about: Have you built similar patterns in other no-code tools? How do you handle the column overhead trade-off? What other architectural patterns from traditional software development translate well to no-code environments?
Are you struggling with these Coda challenges?
-
Need to show Events, Tasks, and Projects in one calendar but they’re in separate tables?
-
Want to combine different table types in a single view without messy mega-tables?
-
Frustrated that Coda doesn’t have UNION functionality like SQL?
-
Looking for a way to merge multiple tables into unified boards, timelines, or dashboards?
-
Need one view for different data types that updates instantly and stays fast?
The SOOT Pattern solves this. It’s a systematic approach to create unified views across different tables without losing performance, native Coda functionality, or data integrity. Used successfully in production docs ranging from pizza shop operations to complex project management systems.
Search terms: Coda union tables, combine multiple tables, unified calendar view, merge different table types, single board for events tasks projects, Coda table consolidation