Home    >    Case Studies    >    Gaming backend management system

Case Study: Gaming Backend Management System


The Database design is based on EAV (Entity - Attribute - Value) model.

  • Less time to design and develop a simple application
  • New entities easy to add and even be added by the end user
  • Create the relationship between the entities dynamically
  • Generic interface components

The Client

Based in Denmark, the client is providing various online games for iPhone and Andriod platforms.

What they wanted

As the client wanted to focus on the development of the client of various games, they then requested Nova to develop the Web Service and backend management system. All data of games will be retrieved from the Web Service and the backend management system is used to manage various games and analyze game data.

The design of the game is like this, it requires various objects can be customized, and each object can have its own properties, which means we need a very flexible database design, the advantage of the design is one database with management system and Web Service can serve multiple games, this makes cost savings and more extensibility.



Database Architecture

Entity – Attribute – Value model (EAV)

EAV is a data model to describe entities where the number of attributes (properties, parameters) that can be used to describe them is potentially vast, but the number that will actually apply to a given entity is relatively modest. In mathematics, this model is known as a sparse matrix. EAV is also known as object–attribute–value model, vertical database model and open schema.

Structure of an EAV table

This data representation is analogous to space-efficient methods of storing a sparse matrix, where only non-empty values are stored. In an EAV data model, each attribute-value pair is a fact describing an entity, and a row in an EAV table stores a single fact. EAV tables are often described as "long and skinny": "long" refers to the number of rows, "skinny" to the few columns. Data is recorded as three columns:

  • The entity: the item being described.
  • The attribute or parameter: a foreign key into a table of attribute definitions. At the very least, the attribute definitions table would contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation, e.g., maximum string length and regular expression, set of permissible values, etc.
  • The value of the attribute.

Screen Shots