FeedRiv

Build The Database Structure

Once the HTML and design have been completed, the next step is to build out the data structures (the database). I like building out the HTML and design first because it shows how the data will be used and often makes it easy to figure out how the data should be structured.

There are many different databases to choose from. At some point I would like to use SQLite as the underlying database but for now, I typically use MySQL. I've been working with MySQL for years and I'm very comfortable using it (I'm not in any way an expert, but I know enough to get work done).

There are many different ways to structure a database but I typically think about how the data is going to be used and then figure out what would be the most obvious way to group that data.

A database table is basically a group of data. The web framework I'm building comes with three tables already setup:

  • Users
  • Password Resets
  • Usernames

Generally, when I'm create a database table, I will always include an id column, a created_at column, and an updated_at column. If the column ends in _at, then it is a datetime field.

If a columns ends in _int2 that means the decimal place has been shifted two places to the right so that the data can be saved as an integer. When using that data, the value will need to be divided by 100 to shift it back to the original value. It is simpler to run math operations on integers than to deal with floating point math. I haven't seen anyone else use the _int2 suffix. It is just something I've found helpful. If the data I was using needed three decimal places, I would save it with a suffix of _int3. That last number indicates how many places the number has been shifted.

You generally want to add indexes to a database to speed up the responses, especially when there is a lot of data. There are generally pretty obvious places for adding indexes (like on the relationship ids), however when I'm starting out with a new project, I usually prefer not to add any indexes and only add them as the need arises (when the responses for certain queries start to slow down).

Here is a breakdown of the initial tables built by the system:

Users

  • id
  • name
  • email
  • password (hashed)
  • data (for any extra data that needs to be saved)
  • encrypted (indicates whether or not encryption is being used when saving data)
  • created_at
  • updated_at

Password Resets

  • id
  • user_id
  • token
  • created_ip (the IP that requested the password reset)
  • used_ip (the IP that completed the password reset)
  • used (whether or not the password reset has been completed)
  • expires_at
  • created_at
  • updated_at

Usernames

  • id
  • user_id
  • name
  • primary
  • created_at
  • updated_at

The tables listed above are the starting point. After examining the HTML pages and the data I'm going to need, I've come up with the following database tables that I need to create:

  • Settings
  • Categories
  • Shared Feeds
  • Shared Items
  • Feeds
  • Items
  • Tags
  • Colors
  • Items Tags
  • Auto Ratings
  • Default Tags
  • Default Colors

Here is a breakdown of how each of those tables are going to be structured in the database:

Settings

  • id
  • user_id
  • name
  • key
  • value
  • editable
  • created_at
  • updated_at

Categories

  • id
  • user_id
  • parent_id
  • name
  • show_tags
  • show_ratings
  • show_colors
  • save_ratings
  • sort_order
  • created_at
  • updated_at

Shared Feeds

  • id
  • real_url
  • last_updated_at
  • created_at
  • updated_at

Shared Items

  • id
  • shared_feed_id
  • title
  • url
  • description
  • type
  • published_at
  • created_at
  • updated_at

Feeds

  • id
  • user_id
  • category_id
  • shared_feed_id
  • original_url
  • real_url
  • title
  • last_updated_at
  • created_at
  • updated_at

Items

  • id
  • user_id
  • feed_id
  • shared_item_id
  • auto_rating_int2
  • rating
  • archived
  • status
  • published_at
  • created_at
  • updated_at

Tags

  • id
  • user_id
  • category_id
  • name
  • created_at
  • updated_at

Colors

  • id
  • user_id
  • category_id
  • score
  • color
  • created_at
  • updated_at

Items Tags

  • id
  • item_id
  • tag_id
  • created_at
  • updated_at

Auto Ratings

  • id
  • category_id
  • word
  • use_count
  • sum_score
  • avg_score_int2
  • locked_score_int2
  • locked
  • created_at
  • updated_at

Default Tags

  • id
  • user_id
  • name
  • created_at
  • updated_at

Default Colors

  • id
  • user_id
  • score
  • color
  • created_at
  • updated_at

If you take a look at the Github repository, you'll see that I've added a migration for each of those tables. A database migration is just a file that tells the database what tables or data needs to be added or set up.

Setting up the database structures is one of the most important parts of building an app so now that we have that in place, the next focus is going to be on connecting everything together.


< Style The HTML Using CSS Build Out The Backend Code >