Let us explore the concept of a Places database for FH a little further.
It is technically possible to create a GEDCOM containing only Place records in FH format and merge that into any Project.
However, there are some challenges to overcome...
Place Column Format
I suspect other products with a Places database have a rigid Place naming structure that all users must follow.
As you have learnt from
Working with Places and Addresses, FH is less rigid and more flexible.
Your Place name columns may involve building, street, parish/district, town/city, county, state, country, etc.
A Places database may have a different column structure. However, that could be resolved with the 'Rearrange Address and Place Parts' plugin.
Database Coverage
FH users focus on ancestors all over the world in Europe, North America, Australasia, India, and elsewhere.
Would a Places database have separate components for different countries or regions?
If the user only loaded one component of the database and searched for say Wellington they may not realise that there are several such places in Australia, Canada, India, New Zealand, South Africa, UK and USA!
Database History
As explained in
Working with Places and Addresses, Places change name and jurisdiction over time.
So which time eras must the Places database accommodate?
Should it provide the contemporary Place names for each location throughout time?
For example, the UK has a very chequered history of changing county boundaries, and near their conception, Australia, Canada and USA did not have those names!
Database Search
To cope with some of the above cases it may be more useful to search Place names from the righthand column end.
i.e. Country and then state or county before town/city.
Taking all the above into account, and given the search capabilities of Google, etc, then is a Places database worthwhile?