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:

    user_idfirst_namelast_nameemail
    54CalebCurryepic@legit.com
    54CalebCurryCooldude@yo.com
    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 

    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”

    Relationships

    Sorry guys, this is not a blog over dating advise. Rather, it is over database design relationships!

    What is a relationship, you may ask? A relationship is the kind of connection an entity has with an attribute and the other way around as well as the connection between multiple tables. Here, lemme’ explain.

    We categorize relationships into 3 groups:

    • one-to-one
    • one-to-many
    • many-to-many
    Continue reading “Relationships”