Well considering the current implementation is basically a SQL in a noSQL database, that would make sense, but I still think it'd be valuable to see them both side by side before we make a decision.

Personally, I still think the data that needs to be stored is better suited to noSQL style (done properly without all the artificial keys and different tables we have now). I'm pretty sure we could consolidate sponsors, hackers, and accounts into a single table and maybe a few more while keeping it very human readable and probably easier on the implementation and troubleshooting side (no hackerID/accountID/etc... mapping to maintain, just nest one inside the other).

We definitely can consolidate it all into one table using Single Table Inheritence, but this has its disadvantage where every field has to be nullable in the database itself.

I have already done some work consolidating all the fields that don't carry extra data into one (see that the Staff, and Volunteer models have been deleted). They will just be checked through the account role.

There remains some work in ensuring that user's cannot set an account type of higher elevation through the regular post route so i'll create some controller that take the proper permissions for this.

Frankly my only concern about schema migrations that occur over time, so we have to ensure we have at least one person that has a strong understanding of SQL on the team. TypeORM has the capability to generate and handle migrations but it's always good to play on the safe side.

Edit: The current application schema is not currently 100% correct, the original layout was meant to support multiple applications using a one to many relationship in the hacker model but due to some bugs I had to temporarily keep the current system. This was meant to solve #650.

Discussion On Database/Schema Design #776

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions