I am working on a feature where I need to store some data and I am not sure what should be my best option to store this data. I am sending data to some third party and want to show some part of that data internally in system dashboard.

Data is being calculated at run time and being sent to third party. Since the base data based on which I am creating data needed for third party can change down the line, I can not use same API to create data in the later stage so I am left with no option but to save it somewhere.

I am not sure what will be the best way to store some part of it. I have following options

  1. Store data in DB as json data and when need to show in dashboard , just fetch it and de serialize it.
  2. Create a new structure for this in DB and store it.

FYI: I am storing data being sent to third party as an XML for logging purpose but not sure if using same XML file at later stage is a good option ( a little doubtful about file system).


The guiding principle at work here is probably "if you ever need to run a query on the data, and not just display it in its native form, then the data needs to be first-class rows and columns, not some JSON stuffed into a single field."

  • I understand that, but there will never going to be any instance where some one needs to be query on this data. this is only for reference purpose – Umesh Awasthi Jun 24 '16 at 0:35
  • Then it doesn't need to be first-class rows and columns then, does it? – Robert Harvey Jun 24 '16 at 0:51
  • Question is what can be the best option for this? As I have to keep these records and show it on the dashboard, since this is not being used in any business calculation / search etc, I was not very inclined to create new DB structure for this. – Umesh Awasthi Jun 24 '16 at 2:42
  • 1
    Then don't. .... – Robert Harvey Jun 24 '16 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.