Skip to main content

Event modeling

On this page you will find the three event data model architectures that Mitzu supports. More information you can find at this blog.

Single event tables​

This is the simplest event data model of all three. Each event you want to track should be a separate table. Each table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
info

In case of single event tables the name of the table describes the event that the user performed.

Wide multi event Tables​

This event table model contains each event in a single table. The event properties for each event are stored in separate columns in the same table. This makes this table "wide" as the properties for each event don't always overlap and 100+ columns are required.

Multi event table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
  • Event name: The name of the event that the user performed.
warning

Maintaining this table has some drawbacks. This table often with 100+ columns, which can be hard to maintain.

info

As this table also contains all events for the product or service, it can also contain a lot of data. This can make this table slow to query. It is suggested to partition this table based on the event_name column and index this table based on the event_time column.

Short multi event tables​

This event table model contains each event in a single table. The event properties for each event are stored MAP, JSON, or VARIANT types in the same table. This makes this table "short" as with a single event_properties column, it is possible to store all the event properties.

Multi event table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
  • Event name: The name of the event that the user performed.
warning

Maintaining this table has some drawbacks. This table often with 100+ columns, which can be hard to maintain.

info

As this table also contains all events for the product or service, it can also contain a lot of data. This can make this table slow to query. It is suggested to partition this table based on the event_name column and index this table based on the event_time column.