Open micahdbak opened 4 months ago
Creating a database table for this feels like overcomplicating it, but it seems like a fine idea. I can imagine eventually connecting user accounts to the data, so people can have a profile that links to their hackathon submissions!
Let's hardcode the data for now & revisit this once we have user profiles set up, OR just combine adding user profiles to this as well. Unless there's some other usecase you think this table is important for?
@EarthenSky , my idea was to have a foreign key for the user submitting it, but you also have to consider there are normally multiple users submitting a project. Nonetheless I wanted to incorporate it with the existing systems & tables :)
@EarthenSky , my idea was to have a foreign key for the user submitting it, but you also have to consider there are normally multiple users submitting a project. Nonetheless I wanted to incorporate it with the existing systems & tables :)
If a team has multiple users, we'd want to somehow connect multiple users to the data, so we'd probably want a hackathon submissions table, and a table for associating users with submissions. SQL makes me so sad :sob: (I'll get over it, haha)
But yeah, the idea seems like it would work, I'm mostly worried about priority.
SQL makes me so sad ðŸ˜
You see, SQL was designed at the same time as entity-relationship table designs.
This problem is easily solved with:
Entity: submission(submission_id, submission_data...)
Relationship: submission_membership(user_id, submission_id)
Entity: users(user_id, user_data...)
Again gabe I urge you to take CMPT 354 or look into designing databases!!!
Every row in submission_membership denotes a user being a member in a group that submitted a given submission. You can define the primary key as being user_id, so a user can only join one group, but that many users can join a single group
I'm mostly worried about priority
And yeah, this is a later thing. But should I have free time I'd like to do this in time for Fall Hacks
You see, SQL was designed at the same time as entity-relationship table designs.
Relationship pattern sounds nice! I still have sadness that a table cell can't contain a list, even though I can tell it's not a great pattern, though my sadness will fade \:)
Title is self-explanatory.
Should be able to store the information from: