DB refactor

[MiniDigger]

the current DB structure is a mess and causes our queries to be a mess which causes everything to be slow and makes changes hard.
I propose completely wiping the DB and starting from scratch (while obviously migrating data over, most likely by having a new DB in postgres and setting hangar into read only while migration happens).

while that obviously seems super dauting and a giant task, I propose refactoring the backend to adhere to domain driven development (DDD) principles, basically splitting everything up into domains (users, projects, versions, pages, jobs, etc) and giving each domain ownership over its tables.
then we can rewrite stuff one by one.

ideally, the domains only expose domain objects, not DB objects, so internal changes in a domain in the future will have no affect on other domains.

I envision a facade infront of a each domain that will only expose strictly typed interfaces.
so a VersionFacade would have a methods getVersion()Version, getVersionWithDependencies()VersionWithDependencies, getVersionWithPlatforms()VersionWithPlatforms, getVersionFull()FullVersion etc., all backed by an internal VersionImpl class that has all these fields.

The facade could also implement all security stuff (if that isnt done in the db queries) and hiding certain fields for certain callers (i.e. IDs shouldn't be exposed in the public api)

list of "requirements":

• need a way to not repeat part of queries all the time
• one rest request ideally is one query
• don't join tables we may need for filters when those filters arent used (or would select everything)
• denormalize some tables to keep joins to a minimal (i.e. the whole version mess) or use materialized views?

[Danieljunek17]

I am interested in helping out writing a optimized db-scheme