Script page Buy (opens Tebex in a new tab)

Database

On this page5

The script installs its own schema. On every start it reads sql/install.sql out of its own folder and runs each statement through oxmysql, then applies the guarded migrations below the -- MIGRATIONS marker. The console prints:

Code

[5code-recognition] Schema ensured (mysql 8.0.39).

Every statement in that file is idempotent, so you can also import it by hand and nothing happens twice. You only need to import it manually in one case — ESX, see Installation step 8.

Supported versions

Engine	Minimum
MySQL	8.0
MariaDB	10.4

An older engine is not blocked, only flagged with one warning:

Code

[5code-recognition] Database mariadb 10.3.39 is older than the tested minimum (MySQL 8.0 / MariaDB 10.4). Continuing, untested.

Tables

Seventeen tables, all prefixed recognition_. Times are BIGINT epoch seconds.

Identity and memory

Table	What it holds
`recognition_identities`	One row per character: its recognition identity (voice and face). The column is named `identifier` on purpose, so `esx_multicharacter` purges it and Qbox owners can list it in `characterDataTables`.
`recognition_memories`	What an observer character remembers about a target character — one row per observer, target, source and disguise slot. Slot 0 is the person themselves; slots 1…n are disguise memories.
`recognition_familiarity`	How well an observer knows a target. Survives memory expiry. Only recognitions that resolved to the real person count.
`recognition_introductions`	Names people gave each other before the listener had a memory to attach them to.

History and evidence

Table	What it holds
`recognition_scans`	Scan history for the admin trend chart and the incident timeline.
`recognition_proofs`	One snapshot per logged action (aim, damage, kill, cuff, uncuff, rob, search, escort, kidnap, and anything a script logs itself as `custom`). Tamper-evident: a deleted or edited row shows up in `recognition:verifyproofs`. Stores both numbers: what the actor remembered, and what they could have reached right then.
`recognition_admin_log`	Every admin view, edit, delete, identity reset, death decision and settings change, with the written reason. Also tamper-evident.
`recognition_anomalies`	Server warnings kept for staff to review.

Papers, photos and devices

Table	What it holds
`recognition_reports`	Camera reports, witness statements and descriptions. The item only carries a report id, so duplicating the paper never duplicates the evidence.
`recognition_photos`	Photos, when `ServerConfig.PhotoHost = 'local'`. Stored as data URI text.
`recognition_devices`	Voice changers, hidden cameras and magnetic scanners: serial, owner, battery, preset. Also the storage fallback for inventories that cannot hold item metadata.
`recognition_items`	Virtual items, used only when `Config.InventorySystem` resolves to `standalone`. Never written when a real inventory is running.

Lifecycle

Table	What it holds
`recognition_death_sessions`	One open or pending New Life Rule session per character, with its witness list and its outcome.
`recognition_identity_resets`	Face implants, export resets and admin resets. Written before money moves, so an interrupted surgery can always be found and finished.

Clothing knowledge

Table	What it holds
`recognition_clothing`	What each clothing item covers, learned by Auto-scan: face coverage, sleeve class, gloves, colours, labels.
`recognition_clothing_baseline`	How many drawables and props each freemode model had at the last check, so a new EUP or addon pack is noticed.
`recognition_settings`	Setting overrides made from the in-game admin panel, so they survive a restart. Anything not overridden comes from `config.lua`.

Migrations

The schema is re-ensured at every start, so an update that adds a column adds it for you. Nothing is ever dropped automatically. The changelog names any migration that needs a hand.

Deleting a character's data

How a deleted character is cleaned up depends on your selector:

Selector	What happens
ESX (`esx_multicharacter`)	Purges `recognition_identities.identifier` itself, as long as our table existed when it started.
Qbox (`qbx_core`)	Purges it once you add `{'recognition_identities', 'identifier'}` to `characterDataTables`.
0R Multicharacter v3	Purges every table you list in `Database.List` — see Installation step 8. On ESX it also re-numbers slots after a delete, which is why every character-keyed column has to be listed.
QBCore, UM, 17mov, CodeM, OP, ak47, VMS	No delete list and no event, so our own clean-up job checks (every 6 h by default) whether each character still exists and removes what is left behind. Seeing a delete happen triggers an early check 10 s later.

Rows in recognition_memories, recognition_familiarity and recognition_introductions that point at a deleted identity are removed by the prune job in every case, whichever selector you run.

MySQL 8 notes

JSON columns have no literal default, so they are NULL until written. Nothing reads them as ''.
The strict default SQL mode (including ONLY_FULL_GROUP_BY) is fine.
The clean-up job deletes old rows in small batches (ServerConfig.Prune.BatchSize, 2 000 rows by default), so it does not hold long table locks.

Retention

Old rows are deleted on a timer. Defaults and the whole privacy story: Data Retention & Privacy.

#Supported versions

#Tables

#Identity and memory

#History and evidence

#Papers, photos and devices

#Lifecycle

#Clothing knowledge

#Migrations

#Deleting a character's data

#MySQL 8 notes

#Retention