Where data lives
When you ask Ronja to build something that keeps data — a tracker, a register, an intake form — she first decides where that data should live. This page explains how she decides, so you know what to expect and what to tell her.
The short version
Section titled “The short version”- Data that comes from somewhere else, or that is calculated from other data, goes in a table.
- A system of record — rows that people or apps create and edit, where the rows themselves are the point — goes in your organization’s managed database, next to your other systems.
- A second managed database is the right call in only two cases, described below. A different team or department is not one of them.
What kind of data is it?
Section titled “What kind of data is it?”| The data… | Where it goes |
|---|---|
| Arrives from another tool, a file upload or an import | An Integration or Foundation table |
| Is calculated from other data — a rollup, a join, a score | A Derived table, or a metric when it is a number people ask for |
| Is a small list people edit, used by one feature — rates, categories, targets | A Dynamic table in that feature |
| Is a system of record — people or apps create the rows, and they need rules such as “every report names a supplier” | A system in your managed database |
Signs of a system of record: two people may edit the same row; a row must not exist without another (a non-conformance report without its supplier); or an app’s form is how rows are born.
One database, many systems
Section titled “One database, many systems”Most organizations need one managed database. A new tracker or register goes into the database you already have, as new tables beside the systems already there. That lets its rows point at their rows — a non-conformance report can point at the supplier it is against — which rows in two separate databases never can.
If your organization has no managed database yet, Ronja creates one and names it for what it will hold — your organization, or a broad area such as “Operations” — rather than for the first app that uses it. Other systems will move in.
When a second database is right
Section titled “When a second database is right”Two facts call for a separate database:
- Someone outside your organization gets a login to it — a customer portal, or a partner who connects directly. Anyone with a login to a database can see the names and shape of everything in it, so the outside-facing data gets its own database, holding only what they should see.
- Its data must be restored, copied or handed over as a unit, apart from everything else. A dev copy and the trash each work on one whole database at a time.
When one of these holds, Ronja creates the separate database and tells you which fact it was for. Otherwise she adds the new system to the database you have.
These are not reasons for a second database: a different team or department, a different app or topic, a tidier name, or a lot of data. Teams that trust each other share one database, and that is most companies. Where a database runs, and how much it can carry, is Ronja’s job.
Nothing in Ronja stops a second database from being created, and there is no approval step for one — the facts above are what decide it.
What Ronja asks you, and what she decides
Section titled “What Ronja asks you, and what she decides”Ronja asks you about the work: who enters the rows and who reads them, what each record must hold, whether anyone outside your company will get access, and whether the data is ever handed over or restored on its own. She decides the technical parts herself — which database, which tables, and how they connect. She won’t ask you whether to make a separate database: your answers about the work decide that.
Who can change what
Section titled “Who can change what”Apps and workflows connect to a managed database through its shared logins: by default a read login and a write login. Any app that holds the write login can change any table in that database. Between colleagues in one organization that is usually the right trade-off, and Ronja mentions it when it matters for what you are building.
Ronja can’t hide a managed database’s data from colleagues: every member can browse every managed database’s tables, and preview their rows, in Ronja. If something must stay private from colleagues — a salary register, for example — tell Ronja before she builds it, and she will ask how you want to proceed.