go-next database design

[frzyc]

The current Optimizer database employs LocalStorage as a way to store key-value pairs(LocalDB), and a somewhat complicated in-memory manager system to ensure data coherency and validation. This is similar to a no-SQL database to to store data, with a lot of caveats. The design of this system is actually trying to simulate a relational database, with data for each element being somewhat flat, and nesting is done using unique keys.

On the migration to go-next with NextJS & supabase, which uses a postgres database, a more SQL-based database. This requires the loosely relational database to be structured in strict relational tables.

Some existing data structures have already been copied over: Missing:

• Builds (5 arts + weapon)
• TC Builds (raw stats for arts + weapon + configuration)
• OptConfig(shared by Optimzier, artifact Upgrader, TC solver)

Note: there are several departures from the localDB-> backend db:

• the concept of users/accounts (since it will store all user data)
• row access security (provided by supabase) for user to edit and update their own data rows (needs to be done pretty much across all tables)
• in GOOD, the artifact.location: characterKey, which characters are unique to each localDB, but now since there is a dedicated table for characters, in the new system, location-> unique character key
• use PostgreSQL indexes to speed up lookup?

[andrewdge]

Dropping for visibility, index design page for when we have to think about how to do indexes