# Schema design: peer review request **URL:** \ **Category:** Store\ **Created:** [October 9, 2018, 7:42pm UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964 "2018-10-09T19:42:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nick.fr](https://avatars.discourse-cdn.com/v4/letter/n/b9bd4f/32.png) [@nick.fr](https://community.influxdata.com/u/nick.fr)\ **Post date:** [October 9, 2018, 7:42pm UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/1 "2018-10-09T19:42:16Z")
Hi all, I’m a total influxdb newbie and I would really appreciate a schema review from experts. My (academic) project is based on some Green Button data (energy consumption in kWh) stored in CSV files. We have one CVS file per site, each containing the following columns: date time utc, consumption value, ‘estimated’ flag. On the other end, we have some metadata concerning the sites: industrial sector, latitude, longitude, time zone. Reading a [previous post](https://community.influxdata.com/t/schema-design-for-iot-metrics/2134) I decided to create a single measurement called ‘energy\_usage’ containing points with the following format : ``` energy_usage_point = { ‘measurement’: ‘energy_usage’, ‘time’: string , ‘fields’: { ‘value’: float }, ‘tags’: { ‘site’: int, ‘industry’: string, ‘latitude’: float, ‘longitude’: float, 'geohash': string, ‘time_zone’: string } } ``` This scheme seems to provide acceptable performances but could we do better? I had a look to the schema design recommandations provided by the (excellent) influxdb doc [1]. The very first recommandation tells us to limit the number of series. My schema generates 205 series [2] for the single measurement we have. Is that to much or acceptable ? Thanks for your help. Nicolas. [1] [https://docs.influxdata.com/influxdb/v1.6/concepts/schema\_and\_data\_layout 1](https://docs.influxdata.com/influxdb/v1.6/concepts/schema_and_data_layout) [2] influx -database ‘mydatabase’ -format ‘csv’ -execute ‘SHOW SERIES’ | grep -v “name,\_id,host” | wc -l ---
**Author:** ![samaust](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/samaust/32/867_2.png) [@samaust](https://community.influxdata.com/u/samaust)\ **Post date:** [October 9, 2018, 11:41pm UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/2 "2018-10-09T23:41:28Z")
I’m assuming that: - You have one sensor per site. - The industry, latitude, longitude, geohash and time\_zone rarely or never changer per site. So I suggest to use two series ```auto energy_usage_point = { 'measurement': 'energy_usage', 'time': string, 'fields': { 'value': float }, 'tags': { 'site': int } } ``` ```auto energy_usage_site = { 'measurement': 'energy_usage_site', 'time': string, 'fields': { 'industry': string, 'latitude': float, 'longitude': float, 'geohash': string, 'time_zone': string }, 'tags': { 'site': int } } ``` You’ll import all your energy measurements in energy\_usage. You’ll import the site information only when it changes, so maybe just once. The site tag will allow to group by “site”. When you want to get the current site metadata, you just do a query such as ```auto SELECT LAST(*) FROM energy_usage_site ``` ---
**Author:** ![nick.fr](https://avatars.discourse-cdn.com/v4/letter/n/b9bd4f/32.png) [@nick.fr](https://community.influxdata.com/u/nick.fr)\ **Post date:** [October 11, 2018, 6:10pm UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/4 "2018-10-11T18:10:17Z")
Thanks Samust. I’m a bit confused cause my need is, for instance, to be able to place ‘energy usage’ data on a map. With the schema you propose, I don’t see how I can do that due to [the following influxdb limitation](https://docs.influxdata.com/influxdb/v1.4/troubleshooting/frequently-asked-questions/#how-do-i-query-data-across-measurements). Clearly speaking, I don’t see how to execute an inner join on “energy\_usage” and “energy\_usage\_site” measurements. ---
**Author:** ![samaust](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/samaust/32/867_2.png) [@samaust](https://community.influxdata.com/u/samaust)\ **Post date:** [October 12, 2018, 12:59am UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/5 "2018-10-12T00:59:32Z")
The other option is to put everything in the same measurement but make industry, latitude, longitude, geohash and time\_zone fields instead of tags, unless you’ve got some good reason to use them as tags. ---
**Author:** ![nick.fr](https://avatars.discourse-cdn.com/v4/letter/n/b9bd4f/32.png) [@nick.fr](https://community.influxdata.com/u/nick.fr)\ **Post date:** [October 12, 2018, 5:01pm UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/6 "2018-10-12T17:01:14Z")
samaust, industry, is one the entities I need to “GROUP BY”. [Influxdb documentation](https://docs.influxdata.com/influxdb/v1.6/concepts/schema_and_data_layout/) says that such data should but a tag in this case. I’m a bit lost… ---
**Author:** ![samaust](https://sea1.discourse-cdn.com/flex023/user_avatar/community.influxdata.com/samaust/32/867_2.png) [@samaust](https://community.influxdata.com/u/samaust)\ **Post date:** [October 14, 2018, 3:07am UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/7 "2018-10-14T03:07:08Z")
That’s what I meant by “unless you’ve got some good reason to use them as tags”. Sorry if I was not explicit enough. I meant to suggest to place the data you want to group by in tags and everything else in fields. ```auto energy_usage_point = { 'measurement': 'energy_usage', 'time': string, 'fields': { 'value': float 'latitude': float, 'longitude': float, 'geohash': string, 'time_zone': string }, 'tags': { 'site': int, 'industry': string } } ``` ---
**Author:** ![nick.fr](https://avatars.discourse-cdn.com/v4/letter/n/b9bd4f/32.png) [@nick.fr](https://community.influxdata.com/u/nick.fr)\ **Post date:** [October 14, 2018, 7:07am UTC](https://community.influxdata.com/t/schema-design-peer-review-request/6964/8 "2018-10-14T07:07:12Z")
Ok. If we move `geohash` to the tags section then I think we have the ultimate schema. Thanks a lot for your help.