Skip to main content
added an important PS
Source Link

Ok, apparently you have three problems.

The first one is the one you described (fetching ALL referrals from one user's tree of referrals); the second one is knowing if a given user is in that tree (without having to fetch the whole tree). You might need this eventually.

For the second problem, you could use Merkle Trees (and specially Merkle Pollards). Something in this direction: medium.com/@jgm.orinoco/understanding-merkle-pollards-1547fc7efaa

But the first problem actually demands that you fetch all descendants (you need to show them on screen). I believe you should have an off-chain system in order to optimize this. You could listen to referral events and update an off-chain database whenever an event is emitted. If something happens to your database, you can always rebuild it from the blockchain data.

The blockchain is still very young to be used as database, but MySQL would eat this problem for breakfast.

Ok, now the third problem? The one to rule them all, and even make the first two problems "obsolete"?

If you have 100 levels of referrals, and if each level has referred only two other users, you already have to show 2**100 names on screen. That's ~= 1,000,000,000,000,000,000,000,000,000,000 names. You don't want to do that, and MySQL will not help you here, either. Maybe you should reconsider your goals. If you have 7 levels of referral, as most schemes seem to use, you already have a lot on your plate.

I hope this helps you on your journey!

PS: That number is MUCH larger than the world's population, by the way. Maybe you should reconsider your expectations, too.

Ok, apparently you have three problems.

The first one is the one you described (fetching ALL referrals from one user's tree of referrals); the second one is knowing if a given user is in that tree (without having to fetch the whole tree). You might need this eventually.

For the second problem, you could use Merkle Trees (and specially Merkle Pollards). Something in this direction: medium.com/@jgm.orinoco/understanding-merkle-pollards-1547fc7efaa

But the first problem actually demands that you fetch all descendants (you need to show them on screen). I believe you should have an off-chain system in order to optimize this. You could listen to referral events and update an off-chain database whenever an event is emitted. If something happens to your database, you can always rebuild it from the blockchain data.

The blockchain is still very young to be used as database, but MySQL would eat this problem for breakfast.

Ok, now the third problem? The one to rule them all, and even make the first two problems "obsolete"?

If you have 100 levels of referrals, and if each level has referred only two other users, you already have to show 2**100 names on screen. That's ~= 1,000,000,000,000,000,000,000,000,000,000 names. You don't want to do that, and MySQL will not help you here, either. Maybe you should reconsider your goals. If you have 7 levels of referral, as most schemes seem to use, you already have a lot on your plate.

I hope this helps you on your journey!

Ok, apparently you have three problems.

The first one is the one you described (fetching ALL referrals from one user's tree of referrals); the second one is knowing if a given user is in that tree (without having to fetch the whole tree). You might need this eventually.

For the second problem, you could use Merkle Trees (and specially Merkle Pollards). Something in this direction: medium.com/@jgm.orinoco/understanding-merkle-pollards-1547fc7efaa

But the first problem actually demands that you fetch all descendants (you need to show them on screen). I believe you should have an off-chain system in order to optimize this. You could listen to referral events and update an off-chain database whenever an event is emitted. If something happens to your database, you can always rebuild it from the blockchain data.

The blockchain is still very young to be used as database, but MySQL would eat this problem for breakfast.

Ok, now the third problem? The one to rule them all, and even make the first two problems "obsolete"?

If you have 100 levels of referrals, and if each level has referred only two other users, you already have to show 2**100 names on screen. That's ~= 1,000,000,000,000,000,000,000,000,000,000 names. You don't want to do that, and MySQL will not help you here, either. Maybe you should reconsider your goals. If you have 7 levels of referral, as most schemes seem to use, you already have a lot on your plate.

I hope this helps you on your journey!

PS: That number is MUCH larger than the world's population, by the way. Maybe you should reconsider your expectations, too.

Source Link

Ok, apparently you have three problems.

The first one is the one you described (fetching ALL referrals from one user's tree of referrals); the second one is knowing if a given user is in that tree (without having to fetch the whole tree). You might need this eventually.

For the second problem, you could use Merkle Trees (and specially Merkle Pollards). Something in this direction: medium.com/@jgm.orinoco/understanding-merkle-pollards-1547fc7efaa

But the first problem actually demands that you fetch all descendants (you need to show them on screen). I believe you should have an off-chain system in order to optimize this. You could listen to referral events and update an off-chain database whenever an event is emitted. If something happens to your database, you can always rebuild it from the blockchain data.

The blockchain is still very young to be used as database, but MySQL would eat this problem for breakfast.

Ok, now the third problem? The one to rule them all, and even make the first two problems "obsolete"?

If you have 100 levels of referrals, and if each level has referred only two other users, you already have to show 2**100 names on screen. That's ~= 1,000,000,000,000,000,000,000,000,000,000 names. You don't want to do that, and MySQL will not help you here, either. Maybe you should reconsider your goals. If you have 7 levels of referral, as most schemes seem to use, you already have a lot on your plate.

I hope this helps you on your journey!