How do you definitively identify a country in your database? It can be pretty challenging because the information changes on a fairly regular basis. Add to that the fact that different “authorities” disagree about what is or isn’t a country, and also some of the best ways of identifying a country are encumbered with fees and/or usage restrictions, and you can see it’s a bit challenging. With the DC_Countries project, we have attempted to create (yet another) standard way of uniquely identifying countries, as well as giving you access to a lot of additional information you may find useful.

The most important part of the DC_Countries standard is the key that uniquely identifies each “country” in the world. DC_Countries does not attempt to distinguish what a country is: it includes countries, political regions, islands, postal destinations, certain military destinations, and other places that some sources consider to be countries that other sources do not. Generally DC_Countries opts to be more inclusive than exclusive, thus you will probably find more “countries” listed in it than you will in many other sources. Ultimately the DC_Countries project team determines which “countries” to include and which to exclude and how to designate them within the database. No political agenda is being promoted by these decisions, but rather it is based on a review of multiple sources of data, current worldwide political trends, and our own personal sense of what seems logical to put into the database. Where conflicting data exists (including spelling and “formal names” of countries), a decision is ultimately made by the team. No decision is final, and we welcome input — especially from local authorities with first-hand knowledge of the local geopolitical and administrative situation in a particular country.

The project will be updated at various times when information is found that needs to be updated. This presents a potential problem for database administrators: as country information changes, should you always use the most current information or should you keep using the historically accurate information so you have a snapshot of the country information at the time the data was stored? DC_Countries helps you with this dilemma by providing both a primary key (DC_Country_Key) with current information and a unique key (DC_Country_Unique_ID) which includes version information so that you can always maintain a method of looking up older information. As the project matures, the historical (i.e., outdated) data may be split off into a related table, but a method will be implemented to provide you with an easy way to cross-reference historical and current data. The database also includes two boolean flags (DC_Country_Active and DC_Country_Retired) to make it simple to select just the type of data you need.

Right now, the project database is sort of an “everything, including the kitchen sink” database and includes a lot of information that may not be useful to a lot of people. We plan to make subsets of the data available in future releases. This will also help to split encumbered data off from our original data, thereby giving you a truly open-source way of tracking country data in your own projects.

Project links: