Relational database when using subgraph for event indexing

The subgraph serves as a relational database in this context. Here are a couple of approaches you can take when storing events as entities or building more descriptive entities to transform the data:

1. Storing events as entities:

   • Each event can be stored as a separate entity, allowing you to easily query and retrieve specific events.
   • This approach provides a straightforward representation of the data, but it may result in a large number of entities depending on the volume of events.

2. Building descriptive entities:

   • Instead of storing events as individual entities, you can create more descriptive entities that aggregate and transform the data.
   • For example, you can create a "protocol" entity that includes counters for activeAccounts or totalValueLocked. This entity can be updated based on the events received, providing a more concise representation of the data.
   • By building descriptive entities, you can simplify the querying process and potentially reduce the number of entities in your subgraph.

Both approaches have their own advantages and considerations, so it's important to choose the one that best suits your specific use case. Additionally, you may need to consider the scalability and performance implications of each approach, especially when dealing with a large volume of events.