Your community webapp stores all its data across 6 tables. Think of each table as a spreadsheet: it holds one type of information, and rows in different tables are linked together using IDs.
The persons table is the heart of the system. Everything — family links, locations, marriage details, tree membership, and account settings — connects back to it.
persons
Core identity · 20 fields · Every community member
Table 02
family_links
Parent, child, sibling & in-law relationships
6 fields · Click to explore →
Table 03
locations
Ancestral, current & business addresses
10 fields · Click to explore →
Table 04
marriage_links
Spouse connections + daughter's dual-tree link
12 fields · Click to explore →
Table 05
tree_membership
Which family tree(s) each person belongs to
6 fields · Click to explore →
Table 06
member_meta
Phone, login, admin flags & privacy settings
12 fields · Click to explore →
Table 01 (core)
persons
Name, DOB, gotra, education, occupation & more
20 fields · Click to explore →
↑ Click any table card to see its full field list
Key Design Decisions
Things worth knowing about how your data is structured
👧
Daughter in Two Trees
A daughter appears in both her birth family's tree and her husband's family tree. Her data is stored once; the marriage_links table holds pointers to both trees so she shows up in both views.
✏️ + 🔗
Text Names + Optional Links
Every "father name" is stored as plain text AND as an optional link to a real registered member. This means the tree works from day one with just typed names, and automatically upgrades when relatives join.
🆔
UUID Primary Keys
Every table uses a UUID (random unique ID) instead of sequential numbers. This prevents ID conflicts when member data is imported in bulk from Excel or CSV files.
How Tables Connect
Every connection between the 6 tables — and what it means
| From Table | Type | To Table | What It Means |
|---|---|---|---|
| persons | 1 → 1 | locations | Each person has exactly one location record (ancestral, current, business) |
| persons | 1 → 1 | member_meta | Each registered user has one meta record (phone, login, admin flags) |
| persons | 1 → many | family_links | One person can have many relationship edges (parent, sibling, child, etc.) |
| persons | 1 → many | marriage_links | One person can have one or more marriage records |
| persons | many → many | tree_membership | A daughter can appear in 2 trees; one tree can have many members |
| persons | self → self | persons | father_person_id points back to another row in the same table (the father's record) |
📐 Relationship Types Explained (Plain Language)
1 → 1 One row links to exactly one row in the other table
1 → many One row can link to multiple rows in the other table
many → many Multiple rows on both sides can link to each other
self → self A row in a table links to another row in the same table
Terms & Definitions
Database terms explained without jargon
Primary Key (PK)
A unique ID given to each row in a table. Like an Aadhaar number — no two rows share the same one.
Foreign Key (FK)
An ID stored in one table that points to a row in another table. This is how tables are "linked" together.
UUID
A long random ID (e.g. a3f4...). Used instead of 1, 2, 3 so records from different imports never clash.
NOT NULL
This field is required — it cannot be left blank when saving a record.
NULL
This field is optional — it can be empty. For example, date_of_death is NULL for living members.
ENUM
A field that only accepts specific values. E.g. gender can only be MALE, FEMALE, or OTHER — nothing else.
BOOLEAN
A TRUE / FALSE field. E.g. is_alive is TRUE for living members and FALSE for deceased members.
VARCHAR
A text field with a maximum length. VARCHAR(120) means up to 120 characters of text.
TIMESTAMP
Stores the exact date and time of an action, like when a record was created or last updated.
Self-referencing FK
A field that points to another row in the same table. father_person_id in persons points to the father's own persons row.
Gotra
The clan name inherited from the father's side. Stored to help validate that a matrimony match is not within the same gotra.
tree_id
A unique ID representing one family's tree (parivar). Multiple members share the same tree_id to show they belong to the same family unit.