0

I have a CosmosDB collection for storing some places information that is using the postal code as partition key. The issue that I'm facing is that for some countries I'm not getting a postal code from google's reverse geocoding api response. Doing a little research I realized that some countries have their owns postal codes systems and it seems like those are not available through google/azure reverse geocoding api. Do I need to change my partition key? The postal code is working like a charm for my searches in countries with postal codes available in google reverse geocoding api.

rmejias
  • 21
  • 2
  • Not sure what you're asking here. If you are unable to get postal codes for some countries, doesn't that suggest **you shouldn't base your partition key on that**? – Lasse V. Karlsen Apr 30 '19 at 15:06
  • Unfortunately, "suggestions are welcome" strongly suggests that this question is asking for opinions, or wants to start a discussion about what to do instead. Neither of those two options are fit or on-topic for Stack Overflow. Unfortunately I will have to vote to close this as primarily opinion-based. – Lasse V. Karlsen Apr 30 '19 at 15:12
  • This is not an opinion based question. This is a question with a set of answers that are correct and a set of answers that are incorrect. There is a wide range of Cosmos DB keys that are obviously incorrect choices. There's also a definite set of key choices that are correct, and any of them will work just fine. – Slothario Apr 30 '19 at 15:16
  • @LasseVågsætherKarlsen I'm asking because maybe there is a workaround for partitioning the data of those countries without postal codes (which are the minority by the way) – rmejias Apr 30 '19 at 15:26
  • 2
    One option is to use a "synthetic partition key" and have a special key for people with null zip codes, or even just have a special code for locations where no zip is found. That could work okay if those locations are only a small fraction of your total and you're not going to have a hugely partitioned database at any point. See: https://learn.microsoft.com/en-us/azure/cosmos-db/synthetic-partition-keys. However, I'd honestly just go with city as a partition key instead. – Slothario Apr 30 '19 at 16:21
  • @Slothario - in this case, there really is no "correct" answer. The choosing of a partition key can not be done in an arbitrary way. It needs to be part of a decision based on the specific types of queries that will be performed. What might seem logical from a general grouping organization might not work for the specific app's needs, and could result in cross-partition scans as the common case. There have been many other similar questions posted to Stack Overflow asking similar questions, many of them closed as "too broad" for the same reasons. – David Makogon Apr 30 '19 at 18:17

1 Answers1

-1

If refactoring your code to use a new key is not currently worth the effort, consider wrapping your geocoding API in a service that contacts other APIs/other logic to get area codes for countries not listed.

You can also use the city name as the partition key. The Cosmos DB documentation actually uses that as an example.

Slothario
  • 2,830
  • 3
  • 31
  • 47
  • Unfortunately, if your answer is just more questions, it's not really an answer for Stack Overflow. Most likely this question is asking for opinions or wants to start a discussion, neither which is fit for SO. – Lasse V. Karlsen Apr 30 '19 at 15:11
  • That's just an objection to my writing style. Nevertheless, I've rewritten my post to sound more authoritative. Also, see: https://stackoverflow.blog/2018/04/26/stack-overflow-isnt-very-welcoming-its-time-for-that-to-change/. – Slothario Apr 30 '19 at 15:14
  • The issue is that there's no way to "guess" the right partition key for the OP. It has nothing to do with an API or wrapping the logic. The partition key will be largely driven by the types of queries the OP needs to do. Same with City Name, or any other property – David Makogon Apr 30 '19 at 18:13