All entries

Published on Feb 15 2022

The implications of changing our database model

We changed our database model. This has implications for the later usage of our e-learning app.

Understanding a db model is the 80/20 of working with developers.

I try to describe this easy enough for #productdesign people. Because it determines what your software can do.

The e-learning standard model

Usual e-learning portals, aka #LMS have a structure like this:

  • courses (top level)
  • modules
  • lessons

This is the standard model, and we were about to adopt it. Our problem was this: what if I only want to send out one lesson and share it on social media?

Our solution

we’ll make the modul much more flexible. A lesson will be called “content” and it’ll contain multiple “content items”.

  • ContentItems can be of many types:
  • Link (to another content item)
  • Text (can be Trix from @rails
  • Video (Embed YouTube)
  • Quiz

How does it look in practice?

Everything you see on the page is a block, and upon rendering the page, all of them have to be queried and assembled on the page.

We might get slow queries later, but we’ll be able to cache them.

We’ll figure out the scaling later 😅

How Notion handles it

There's a great post by @NotionHQ explaining their block model.

We'll probably learn a lot from them in the next days.

Here's the post: The data model behind Notion's flexibility

Got Feedback?

To my #Developer friends out there:

  • What do you think?
  • Where will we run into problems later on?
  • Would love to know.

    This post is based on a Tweet by @till_carlos on February 15th, 2022.

RandomKPI logoPairing.dev
Location logo

Location:Pairing OÜ Sakala 7-2, 10141 Tallinn

email icon

Email:info@pairing.dev

phone logo

Phone:+1 929 260 1944

@ 2022 Pairing OÜ All Right Reserved