Question

I have taken on a project from a client which requires me to set up a backend server and API (PHP) with communication to/fro an iOS App. I can’t go into too much detail about the app, but for the most part, it is socially based and therefore requires me to constantly update the database upon receipt of a request.

Currently, the database consists of three tables (with a fourth coming soon for comments) Users, Venues and Queues. At the moment, whenever I have a request, I just retrieve the relevant data from the database, but I am starting to wonder whether I need to start implementing methods to improve the ‘scalability’ of the database or use (something along the lines of) memcachd or Redis to improve something or other. Is this necessary as the app is social and may potentially have a large user base? And am I using a good well-performance database for hundreds of requests per second, or should I switch to another?

Thanks in advanced,

Max.

P.S Feel free to pick apart my structure, put it in the post just incase anyone had any interest in taking a look!

CREATE TABLE `Queues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userID` int(11) NOT NULL,
  `Creation_Date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `venueID` int(11) NOT NULL,
  `Wait_Time` int(10) NOT NULL,
  `Line_Length` int(10) NOT NULL,
  `Note` varchar(250) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=13 ;


CREATE TABLE `Users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `First_Name` text NOT NULL,
  `Last_Name` text NOT NULL,
  `Username` text NOT NULL,
  `Password` text NOT NULL,
  `Email` text NOT NULL,
  `Signup_Method` text NOT NULL,
  `Signup_Date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Number_of_Lines` int(11) NOT NULL,
  `Number_of_Venues` int(11) NOT NULL,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=27 ;


CREATE TABLE `Venues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userID` int(11) NOT NULL,
  `foursquareID` int(11) NOT NULL,
  `Name` text NOT NULL,
  `Latitude` text NOT NULL,
  `Longitude` text NOT NULL,
  `Address_Line1` text NOT NULL,
  `Address_Line2` text NOT NULL,
  `Post_Code` text NOT NULL,
  `Country` text NOT NULL,
  `Description` text NOT NULL,
  `Created_At` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;

Answer 1

You can put off worrying about caching methods until the need arises. For the time being, ensure your database is properly normalized. Once the site is working smoothly and starts to gain popularity, hooking in memcached will be a relatively trivial task.

I notice a queue could belong to a user that’s different than the user that owns the queue’s venue: Queues.userID and Venues.userID via Queues.venueID. If this is not what you want then you’ll want to remove Queues.userID as the user info can be obtained be checking the queue’s venue.

Also, if Users.Number_of_Venues is a count of the number of Venues with a certain userID, remove it as there’s no reason to store it as that information can be obtained by a quick COUNT(*). To leave it would mean lack of normalization.

Once your schema is set, remember to properly index. That will be a life-saver in speeding up your queries.