Database Clustering Tutorial 1 – Intro to Database Clustering

Here we are going to be discussing database clustering. Database clustering is when you have multiple computers working together that are all being used to store your data.

There are four primary reasons you should consider clustering:

  1. Data redundancy
  2. Load balancing (scalability)
  3. High availability
  4. Monitoring and automation

Data Redundancy

With database clustering, multiple computers work together to store data amongst each other. This gives us the advantage of data redundancy.

Continue reading “Database Clustering Tutorial 1 – Intro to Database Clustering”

Intro to MongoDB

Intro to MongoDB

What is Mongo DB?  MongoDB is an unstructured database that is becoming extremely popular for speed, ease-of-use, and scalability.

The Problem with Structured Data

Until now, the majority of the my content has covered relational databases. You communicate with a relational database using SQL (Structured Query Language). A relational database follows a structure defined by columns in a table.

The problem with a structured database is that it can become too structured and require a lot of resources to create and design a good database. For instance, I have a fifty part YouTube series just on how to design the structure of a relational database, and that doesn’t even talk about how to use the database.

Just to show one example of this, what if we have a table that defines some structure and for a specific row we want to have some extra data?

Continue reading “Intro to MongoDB”

C Programming Notes

Upon signing up for the newsletter, you’ll receive a welcome email with a link to the get the C Programming notes. You’ll likely also be interested in my C Programming Crash Course. Enjoy 🙂

Currently not running my newsletter, so get the notes here.

C Programming Notes! 

Subscribe to our newsletter to get notes and latest content by email.

    We won’t send you spam. Unsubscribe at any time.

    Powered By ConvertKit

    Introduction to Indexes

    This will be a blog dedicated to designing relational database indexes. By this I mean we will be discussing the important topics of indexing a database but we will not be programming any SQL. This is all part of database design.

    What is an index?

    Wow, such as awesome question! An index allows us to select data from our table much quicker. Think of an index in a book…If you want to know something about a specific topic, you check the index.

    Continue reading “Introduction to Indexes”

    Introduction to Database Normalization

    Any time that you design a database you will have to use normal forms. Normal forms are steps used create the best database design.

    Good database design prevents non-scalar data. Non-scalar data is data that does not store only one value. Having non-scalar data violates the rule that everything should be atomic.

    Good database design prevents repeating data. For example, take a look at this incorrect table:

    Continue reading “Introduction to Database Normalization”

    Cardinality and Modality

    In the blog about designing binary relationships, I briefly described crow’s foot notation. Crow’s foot notation is a design technique that visually explains our relationship between tables.

    In order to understand crow’s foot notation, we must first understand the basics of database design. I recommend you read the previous blogs listed to familiarize yourself with all of the database relationship concepts:


    Cardinality refers to the relationship between a row of one table and a row of another table. The only two options for cardinality are one or many.

    Example: Think of a credit card company that has two tables: a table for the person who gets the card and a table for the card itself. A row from the card_holder table would have a relationship with a row in the card table because the card_holder holds the card.

    Here is an example of a one to one relationship.

    Continue reading “Cardinality and Modality”

    Designing Binary Relationships

    We talked about relationships in the relationship blog. We talked a little about how to structure relationships in a database, but this blog will be dedicated to specifically that.

    One to One

    One to one relationships over multiple tables are not very common. This is because a one to one relationship can be stored in one table.

    Think of the example of a user table and a social security number (SSN) attribute. This would be unnecessary:

    Here is an unnecessary table structure. The SSN (social security number) has its own table even though this could easily be put as a column in the user table. 
    Continue reading “Designing Binary Relationships”

    Introduction to MySQL Workbench

    This will be a quick blog teaching you how to start using MySQL workbench. Although MySQL Workbench is obviously for MySQL, we will be using it to design databases for pretty much any RDBMS. If you have a different modeling program that you prefer, use it! Now that we know the basics of database design we will be really diving into things.

    MySQL Workbench is an entity relationship diagram designing program. An entity relationship diagram (ERD) is a visual representation of our database structure. You may also hear Enhanced Entity Relationship Diagram (EERD), Which is an ERD with more functionality. We typically ignore row values and only worry about tables and columns. Now, let’s begin!

    Continue reading “Introduction to MySQL Workbench”

    Introduction to Keys

    In my blog about relationships, I explained that we often separate information across multiple tables. This is the beauty of a relational database! The added complexity can take a lot to get used to, but having multiple relations (tables) simplifies data! It removes redundant information and has the capacity to store large amounts of complex data. The use of multiple tables suggests that we need to use keys. A key is a column within each database table that keeps an individual row unique. Not only do keys allow each row to be unique, but they allow us to connect tables by using multiple keys. I’ve used this picture before, but it illustrates things perfectly:

    Continue reading “Introduction to Keys”