Goal
Draft an initial SQLite schema for local/offline PluralBridge data storage.
The first version should focus on a practical local database shape that can support preserved export data, future local viewers, validation, and reporting.
Why this matters
PluralBridge should support a portable local/offline data path. SQLite is a good fit for local viewers, test fixtures, lightweight reporting, and cross-platform tooling.
The SQL Server path already helps prove relational loading and reporting. A SQLite path would make local/offline use easier for regular users and future client-side applications.
Suggested scope
Create an initial SQLite schema draft that maps a small useful subset of preserved data, such as:
- user/me identity metadata
- members
- groups
- front history
- custom fields
- member field values
- privacy buckets
- notes metadata or notes content shape
- avatar manifest references
The first version can be a draft. It does not need to fully replace the SQL Server scripts.
Suggested repo location
Possible locations:
scripts/sqlite/docs/sqlite-schema.mdexamples/sqlite/
The exact location can be decided during discussion or implementation.
Safety requirements
Do not use real Simply Plural exports.
Do not include real System data.
Do not include real member names, avatar files, notes, messages, friend data, fronting history, API tokens, authorization headers, screenshots, logs, or database files created from real exports.
Use synthetic fixtures only.
Design notes
The schema should prefer portability and readability.
It should avoid assuming that users have SQL Server installed.
It should support future local viewers without requiring a server database.
It should preserve enough source identifiers to support traceability back to exported JSON.
Possible follow-up work
Later Issues can add:
- SQLite import scripts
- SQLite validation queries
- sample reports
- app/viewer integration
- migration from JSON export to SQLite
- tests based on synthetic fixtures
Acceptance criteria
- An initial SQLite schema draft exists in the repo.
- The draft identifies tables and key relationships for a useful subset of preserved data.
- The draft states assumptions and open questions.
- The draft uses only synthetic examples or no example data.
- No private export data, tokens, notes, messages, logs, screenshots, avatars, or database files are included.
Goal
Draft an initial SQLite schema for local/offline PluralBridge data storage.
The first version should focus on a practical local database shape that can support preserved export data, future local viewers, validation, and reporting.
Why this matters
PluralBridge should support a portable local/offline data path. SQLite is a good fit for local viewers, test fixtures, lightweight reporting, and cross-platform tooling.
The SQL Server path already helps prove relational loading and reporting. A SQLite path would make local/offline use easier for regular users and future client-side applications.
Suggested scope
Create an initial SQLite schema draft that maps a small useful subset of preserved data, such as:
The first version can be a draft. It does not need to fully replace the SQL Server scripts.
Suggested repo location
Possible locations:
scripts/sqlite/docs/sqlite-schema.mdexamples/sqlite/The exact location can be decided during discussion or implementation.
Safety requirements
Do not use real Simply Plural exports.
Do not include real System data.
Do not include real member names, avatar files, notes, messages, friend data, fronting history, API tokens, authorization headers, screenshots, logs, or database files created from real exports.
Use synthetic fixtures only.
Design notes
The schema should prefer portability and readability.
It should avoid assuming that users have SQL Server installed.
It should support future local viewers without requiring a server database.
It should preserve enough source identifiers to support traceability back to exported JSON.
Possible follow-up work
Later Issues can add:
Acceptance criteria