I have an application that has use cases relative to where it is used. A local client and server, where all the server data is in a single location and the client queries that server knowing it is all from that single location.
However the 2nd use case, the client application may connect to several of these location-based servers from which it must know the location from where the data comes.
So in the 1st use case location data is irrelevant, and not necessary to store location. However in the 2nd use case to make querying simple, each record should have a location stored with it.
So my 2 solutions are:
send out location as metadata in queries from each server, create new extended schemas for a database local to the client for cached querying. This would essentially require a 2nd implementation of the client with extended view models.
Both use cases can be satisfied if the location is stored with every schema without having 2 different implementations, but this seems redundant.
Seems a bit overkill if I have to add a location field to every entity or new entity schema, but I think the redundancy is worth it than writing 2 different implementations of the client, or is there a better way?
Im using C# and Postgresql for my server and client apps.