Anyone who has written a report against NEC Housing knows the moment. You have two tables, you know they relate, and you cannot remember how. The column names are cryptic, the obvious foreign key is not there, and the documentation describes the screens rather than the data. So you open three old reports, copy a join you half trust, and hope.
That moment is not a knowledge gap. It is a map gap.
The join you need is rarely a foreign key
NEC enforces most of its relationships in the application layer, not as database constraints. A works order belongs to a property through WOR_PRO_REFNO, but that link is not declared as a foreign key in the schema. Build a path finder that only trusts declared keys and it will route you around the obvious joins and through tables no one would ever use by hand.
SELECT wor.wor_srq_no || '/' || wor.wor_seqno AS works_order,
pro.pro_address
FROM works_orders wor
JOIN properties pro
ON wor.wor_pro_refno = pro.pro_refnoThe relationship is genuine, used in report after report, and completely absent from the constraint catalogue. The schema knows it. It just never says so.
A map you can actually search
The members wiki holds every live NEC table we work with: its columns, types, primary key, the foreign keys in and out, and the verbatim NEC column descriptions where they exist. On top of the declared keys we layer the joins that are real but undeclared, mined from a corpus of working reports and verified, so the map reflects how the data is used and not just how it was constrained.
You can search it, jump between tables by following the links, and read a table’s whole neighbourhood on one page.
From two tables to working SQL
The part people reach for most is the join-path finder. Pick a start table and an end table and it returns the shortest sensible route between them and writes the SQL. Ask it for works orders to tenancies and it gives you the path a housing officer would actually take, through the property and the tenancy holding, rather than a technically valid detour through admin geography.
There is a 3D explorer too, for when you want to see the shape of a subject area and how its tables hang together rather than chase a single path.
None of this replaces knowing your data. It removes the part of the job that was never really knowledge: remembering which of a thousand tables connects to which, and through which cryptic column. That is what a map is for.
