This PR proposes replacing the token_balances table with the account_activity table. The key changes and rationale are as follows:
Purpose: The token_balances table was originally intended to represent the pre_token_balances and post_token_balances fields from the transactions table.
Redundancy: Upon review, it was determined that the account_activity table already serves this purpose, covering both balances and token balances.
Data Structure: The pre_token_balances and post_token_balances fields in the transactions table have a complex type: array(row(account varchar, mint varchar, owner varchar, amount decimal(38,18))).
Alternative Approach: Instead of using complex types, we could represent this data as a string in the transactions table:
CREATE TABLE IF NOT EXISTS transactions (
-- other fields ....
pre_token_balances String,
post_token_balances String,
-- other fields ...
)
The string format could be: (account1, mint1, owner1, amount1), (account2, mint2, owner2, amount2)
Evaluation: While this approach aligns with Dune's implementation, there's no clear advantage to including these fields in the transactions table. The same information can be more easily accessed through the account_activity table.
This PR proposes replacing the
token_balances
table with theaccount_activity
table. The key changes and rationale are as follows:Purpose: The
token_balances
table was originally intended to represent thepre_token_balances
andpost_token_balances
fields from thetransactions
table.Redundancy: Upon review, it was determined that the
account_activity
table already serves this purpose, covering both balances and token balances.Data Structure: The
pre_token_balances
andpost_token_balances
fields in thetransactions
table have a complex type:array(row(account varchar, mint varchar, owner varchar, amount decimal(38,18)))
.Alternative Approach: Instead of using complex types, we could represent this data as a string in the
transactions
table:The string format could be:
(account1, mint1, owner1, amount1), (account2, mint2, owner2, amount2)
Evaluation: While this approach aligns with Dune's implementation, there's no clear advantage to including these fields in the
transactions
table. The same information can be more easily accessed through theaccount_activity
table.Dune query fetching
post_token_balances
andpre_token_balances
intransactions
tableDune query fetching the same info via
account_activity
table