Database Field/Column Naming Convention – Camel Case vs Snake Case

           Many people would argue that it is the choice of developers and be consistent in naming the field names in the databases. Yes, that’s true. But my personal recommendation is to use snake case considering multiple factors. The main theme of this post will revolve around polyglot persistence.

           If you are going to develop any service, the data will be persisted in a primary database (SQL/NoSQL). Based on the other requirements, we might have to store the data in the other databases such as Redis, Elasticsearch or any other data store for low latency queries, analytics etc.

           Each data store follows different naming standards and snakecase is supported universally. Assume you are going to use camel case format and what If one of the data store you use doesn’t recommend camel case. You will have to store the camel case field with lowercased (E.g. readOnly will be used as readonly) or write a mapping layer in between. This is kinda confusing as the application grows.

           Universally all the database supports Snake Case and using this approach would avoid many more confusions If you are going to use polyglot persistence.

Leave a Reply