4 ms·

It really depends on the data structure. If you've got something that can have an unknown amount of variables in it and you're already serving up JSON, then I t

It really depends on the data structure. If you've got something that can have an unknown amount of variables in it and you're already serving up JSON, then I think using JSON is the way to go. Another use-case: We've got hundreds of clients that send health statuses for a ton of different metrics every 10 minutes. Stuff like Wifi strength, exceptions caught/uncaught, various errors and crash reports, blah blah. Anyway, we need a flexible store for all of this stuff because we're always adding more metrics. Whatever the clients send as their request body gets added as a JSON object. We also want to dynamically display all of these metrics. We can literally grab the data as JSON and make the keys table column headers in an html view. Adding new metrics can automatically be reflected in both the database and in our html views. We can query against new fields without changing schemas or business logic.

film42 14y ago
If it were up to me, I would create a schema for each metric and then if you need all on one page, create some nice /client/client_id/metrics/all route. Although if you're dealing with metrics, you probably want to have a good defined model of your data (schema), because statisticians want to know what they have to work with, and saying, "bunch 'o JSON" is not acceptable. Plus there's things like null values to deal with. Yuk. For my startup, we find the common denominator of social media data. For example, a tweet is very unique so it's itself. But then there's more generic types like photos. So then we look at photo services like flickr and instagram. We then evaluate the data available and look for common denominators again to hone in on as much similar data as possible. The result is a model of photo data from a wide range of sources, but are now unified. We could have just used instagram json and flickr json and tossed in the db, but because we defined a schema/ models to get data from, we can sleep soundly knowing the data we send to the frontend is fast and always valid.
- tracker1 14y ago
  Until you have 20-30 joins for a single query, and it takes forever to return simple results against what should be a really simple query/search.
  - film42 13y ago
    This is very true, however it's a problem with your schema/ db types design/ caching. My main argument is using a random data blob is suicidal.

film42 14y ago

If it were up to me, I would create a schema for each metric and then if you need all on one page, create some nice /client/client_id/metrics/all route. Although if you're dealing with metrics, you probably want to have a good defined model of your data (schema), because statisticians want to know what they have to work with, and saying, "bunch 'o JSON" is not acceptable. Plus there's things like null values to deal with. Yuk. For my startup, we find the common denominator of social media data. For example, a tweet is very unique so it's itself. But then there's more generic types like photos. So then we look at photo services like flickr and instagram. We then evaluate the data available and look for common denominators again to hone in on as much similar data as possible. The result is a model of photo data from a wide range of sources, but are now unified. We could have just used instagram json and flickr json and tossed in the db, but because we defined a schema/ models to get data from, we can sleep soundly knowing the data we send to the frontend is fast and always valid.

tracker1 14y ago
Until you have 20-30 joins for a single query, and it takes forever to return simple results against what should be a really simple query/search.
- film42 13y ago
  This is very true, however it's a problem with your schema/ db types design/ caching. My main argument is using a random data blob is suicidal.