Which Query Option Is Better

Hi,

I am building a small dating app (very similar to Tinder).

The application allows users to checkin to venues, and then they can anonymously ‘like’ other users who have also checked in to the same venue. If two users happen to like each other, it’s a Match.

I have the following tables:

USER
ID
Name
Gender
Email
Password

VENUES
ID
Name
GeoLocation

CHECKIN
ID
UserID
Venue
TimeStanp

LIKES
ID
TimeStamp
Sender
Receiver
Venue

One of the main tabs on the app is called Matches, which shows all of your matches.

QUESTION
I am trying to decide whether I should create a MATCHES table and insert a record into it every time there is a match between two users, OR should I just query the LIKES table and return the matches from there?

The LIKES table will no doubt be the largest table in the database, so I thought creating a MATCHES table would greatly improve performance. Once a record is put into the Likes table, it will not be updated or deleted, so there will be no mismatch of information, however i still think i am duplicating data here…

What is your opinion on this? What option would you go with? Thanks in advance.

Uhm, conceptually, are you sure this is a good idea? There are a lot of creepers, stalkers and outright rapists out there and this app sounds like a powerful tool for them to sign up to get the pictures of the ladies they might best attack. I seriously doubt any women will sign up for this.

If you want to build a revolutionary dating site build one that has a penalty for bad behavior that can be enforced. Charge a small cover charge to join (say, USD $5 ) - not enough to run the site, just enough to make it hurt a little if the account gets banned and also giving you a fingerprint of sorts through the credit card # used. If you have to ban a user for bad behavior and they try to sign up again you can block it or punitively double the fee for each time they’ve been banned.

Cause, at the end of the day, it’s the jerks making the online dating experience bad for women which in turn causes them to go all ice queen on the messages they are getting (or leave the site entirely) which makes the non-jerk men miserable and, in the end, everyone gets to be miserable and every online dating site to date has been more or less a failure.

When designing social media apps ask yourself “What is the most nefarious way this could be abused?” In the case of your app, it could outright get someone killed in a small enough venue with the right smuck present.

What kind of database are you planning to use? The answer differs a lot, depending on the type of database you will be using.

@Michael_Morris - although I agree with your concerns, the “fingerprint” suggestion with credit cards means meeting extensive legal criteria in terms of data security, which means a lot more jumping through hoops and more costs than the OP would normally have. I am also not a proponent of not moving on an idea, just because it could be abused. Almost anything you can think of can be abused in some stupid or absurd way and even dangerously. Yes, an idea shouldn’t make any kind of abuse easy. But, possible abuse shouldn’t also stop the idea from happening. If that were always true, we’d still be in the stone age today.

Scott

Not really. Remember, hashing is a one way process. Call sha256(‘ccnumber’ . ‘ccbillingaddress’ . ‘serversalt’). All you need to know is if the card has been used, you don’t need to store it in a retrievable manner.

And there’s abuse, and there’s getting someone killed. An app that lets a rapist know your in the same building with them could get someone killed.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.