eric-tran2/Creatr

Schema suggestions

Closed this issue · 7 comments

Good job with the schema! A few suggestions:

  1. Flickr requires more info on sign up than just an email. You'll want to store all of that info in your user model.
  2. Flickr uses email addresses rather than usernames for signing in, so just specify email rather than email/username.
  3. Will want to add tables and fields related to albums now that you have made that an MVP.
  4. You don't need to store an image_url in the photos table (but you will want it in your state). We will use AWS and ActiveStorage to handle that.
  5. In bullet points after each table, specify the tables that each foreign key references. (It would also be good to add the has_many / belongs_to associations you plan to use.)
  6. Not clear what the favorited_id refers to in the Favorites table. Is this a user?
  7. Tags should only have 1 primary key.
  1. added first name + last name. saw that on the flickr sign up there is an age requirement for signup but will it be necessary to include age as well or could I leave it out? (Does it have to be a 1:1 clone?)
  2. changed email/username to just email
  3. added albums table
  4. removed image_url from photos table
  5. added bullet points for each table
  6. when creating this table, basically referring to the user (user who favorite'd a photo) , similar to like liker id
  7. made tags to only have 1 primary key

Good work. A few comments on the updates:

  1. You do want to try to clone Flickr as closely as possible, so yes, I would include age in your sign up requirements (even if you don't end up using it much / at all).
  2. You want to keep naming conventions consistent, so put an underscore between the components of firstname and lastname.
  3. You list an index for first and last names. Would be worth thinking about whether this is necessary. If you are going to be looking users up in the db by those fields frequently (e.g., allowing users to search for people by first and/or last name), then yes. If not, probably not necessary. If you decide to keep the indices--and it's fine if you do--list them in the table as well.
  4. Can't add an index for comments on photos table because there is (rightly) no comments field. Could add a has_many association though.
  5. Photos shouldn't have a has_many association for photos.
  6. favoriter_id might be a bit more semantic than favorited_id.
  7. I'm a still a little unsure as to the difference between likes and favorites. Does Flickr allow both, or does it just call likes faves?
  8. Does Flickr allow comments on albums? If so, you could make the comments table polymorphic. If not, just leave it as is.
  9. The last few tables need to identify the tables that their foreign keys reference. Page also seems to run out of steam identifying associations as it nears the end.
  1. added age to users table
  2. added _ for firstname/lastname
  3. index for first_name/last_name is not necessary so will be removing
  4. silly mistakes 😢 , changed add_index to has_many comments
  5. removed has_many photos for photos table
  6. changed favorited_id into favoriter_id for semantic purposes 👍
  7. I dont know why I assumed there were both, never been on flickr before but just made an account. I just assumed that there would be a likes and favorites ( favorites > likes , 'i like that photo vs this is one of my favorite photos). Will be removing the likes table
  8. After looking at albums on Flickr, I dont think they allow comments on albums so will be leaving as is
  9. added necessary associations and identified the foreign key references

Good job! Just a couple minor things:

  1. Photos table still has a has_many photos association
  2. I believe favoriter_id should reference the users table instead of the favoriter table. same with commenter_id under comments.

Also, consider adding some compound indices with uniqueness constraints so that a user could only favorite a photo once, and a given tag can only be added to a photo once. (Remember, too, that a compound index will automatically create an index for the first column specified, so you would not need to create another index for that column.)

One other thing to think about: Flickr keeps track of views, so you'll need to store that info in your database too (that way the info will persist)

  1. Removed has_many photos under photo association
  2. changed favoriter_id/commenter_id referencing users
  3. added uniqueness for favorites and tags
  4. added views for photos