This article looks at a practical way to model operator-provided prepaid products without creating either an enormous table full of nullable columns or an unstructured JSON blob that becomes impossible to query. Product A Price: 10 EUR Recipient receives: 10 EUR airtime Product B Price: 10 EUR Recipient receives: 8 GB data for 14 days The purchase price is the same.
This article looks at a practical way to model operator-provided prepaid products without creating either an enormous table full of nullable columns or an unstructured JSON blob that becomes impossible to...
Product A Price: 10 EUR Recipient receives: 10 EUR airtime Product B Price: 10 EUR Recipient receives: 8 GB data for 14 days The purchase price is the same.
A schema should therefore avoid assuming that: purchase_amount == recipient_amount A useful base model might begin with: products -------- id provider_id external_product_id operator_id country_code...
The page is ready to read now. The fuller skim-friendly version will appear here automatically.
This article looks at a practical way to model operator-provided prepaid products without creating either an enormous table full of nullable columns or an unstructured JSON blob that becomes impossible to query. Product A Price: 10 EUR Recipient receives: 10 EUR airtime Product B Price: 10 EUR Recipient receives: 8 GB data for 14 days The purchase price is the same. At that point, amount is no longer a product model.
At that point, amount is no longer a product model.
A schema should therefore avoid assuming that: purchase_amount == recipient_amount A useful base model might begin with: products -------- id provider_id external_product_id operator_id country_code product_type display_name purchase_amount purchase_currency recipient_value recipient_currency active For general airtime: <s...
Open the app view to save this story, compare related coverage, and continue from the same source.