I have a table called Billing, which is basically a receipt (for different types of transactions). The app has a feature that you can create new charges (well, all charges except for tax and other constants). Since there would be a dynamic number of charges, we decided to store the charges for a billing on a single text field with a JSON structure. So the Charges column contains stuff like this:
{"CrateFee":50,"DeliveryFee":90,"PackagingFee":20}
{"DeliveyFee":90,"ServiceCharge":200}
Our alternative would be to create a separate table for these charges, with this structure:
Charges
BillingId | ChargeName | ChargeValue
1 CrateFee 50
1 DeliveryFee 90
1 PackagingFee 20
2 DeliveryFee 90
2 ServiceCharge 200
We decided against the second method because it would be populated by tens of thousands of rows in just a single day (estimate is about a thousand transactions in a day). I know we’ll be limited with what we can do with the data if we use the first one, so I really want to push the separate table method. But I have no idea on scaling, optimizing, etc. when it comes to databases, so I need some help with this.
Is it OK to use the second method? How will this impact performance? Are there other alternatives?
The first implementation might make it easier to sstore the data in a single line, but you are opening yourself to a whole world of hurt.
By correctly using indexes on the fields, you should not have major issues, so i would recomend the second approach.
Also, at some later stage you can try implementing archiving, which should also help with the size of the second table.