Yes you should version your database

There is one major process that your team is likely ignoring that holds a large stake in your application, can you guess what it is?

Did I hear someone say Database migration woop woop top of the class!

More often than not, we properly version code but deploy the database as one big sql dump. Practically all teams I have interacted with during deployment present a .sql file with instructions that Mysqldump or a similar tool should be put to employ.

The biggest disadvantage to this method is that the database and the application don’t remain in sync for the various versions available. At first glance this may not seem like that much of an issue since most of the time we are only concerned about the final version of the db. However when you think about it you realize that if the version of db you have is only the latest, then earlier versions of the code are practically unusable since they work with the implicit assumption of how the schema of the database is structured.

Application <-> Database mismatch maybe your biggest problem but other problems quickly become apparent when you deploy and need to scale your app. Since the entire db is just one big dump, you can not easily automate the task of scaling it over the cloud.

Well now that we have talked of the evils of the dump, what can we do?

The easiest option is to store diffs of the database. Here I don’t mean in the sense that git does but rather storing ALTER scripts in an orderly incremental manner in a folder called migrations. Sample contents would be:

  • 001_Users.sql
  • 002_Products.sql

And when say we alter the users table then:

  • 001_Users.sql
  • 002_Products.sql
  • 003_Altered_users.sql

etc

We then commit the files to our code repository of choice.

This ensures that at whatever point you checkout your code, you can also be able to generate the necessary schema.

Other considerations

For those who work with frameworks, your framework probably ships with a schema builder in one form or another. For those cases you may wish to version the schema files rather that the sql file.

For those of us who prefer the db to be framework agnostic, the following tools can be a great help to help you run your diffs

How do you manage database migrations within your own team? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Common implementations of MVC pattern

As far as design patterns go, MVC is the most well known pattern.

Model

This component contains the data structures and logic that are unique to your business. That is what the application does to add value.

Examples of this would be your firebase models.

View

This component interacts with the users of the application.An example would be the html rendered in the browser.

Ideally, the view should listen for changes in the model and respond to them.Most modern Javascript frameworks allow you to do this.

Controller

The controller processes requests incoming from the user and sends them to the model as commands.

Of course the pattern is a general principal. To its end a couple of popular implementations have emerged which we will look into in brief.

Configurator/Actor

In this pattern the controller writes out a request to shared file such as a dot file. A daemon running in the background would then read this file and perform an activity based on it.

Spooler/Daemon

This particular pattern is best illustrated by the print spool. The front end (your machine) drops files to be printed in a spool area. A printer daemon running in the background watches for new files and send them out to the printer. Once the job is done, the file is removed from the spool area.

It is noteworthy that this pattern would work well with jobs that would benefit from batch processing.

Driver/Engine

In this pattern the driver provides commands and interprets output from an engine after startup. An example of this would be where a utility meant to periodically fetch content from say ten different websites starts up curl in the background and uses it to do the actual fetching.

Client/Server

This is the browser/server pair where requests are sent to a daemon running in the server such as nginx which then processes the request and sends a response back.

This pattern can be thought of as an implementation of the Driver/Engine pattern.

Do you know of any other implementation of the MVC pattern? Talk to us in the comment section below

Facebooktwittergoogle_plusredditpinterestlinkedinmail