1

The project is a read-only interface for a company database.

In the database, there is some 'static' data about departments, in a Departments table. The value of these fields don't change with time (eg. DepartmentID, DepartmentName, DepartmentDescription, HistoryTableName, etc.).

There is also some timestamped data. The historical data for each department is stored in a dedicated table (named HistoryTableName, with fields such as timestamp, numberOfEmployees, Energy Consumption, ...). As you can guess, the layout of the data is not something that can be changed is this scope.

The point of the interface is to be able to access the data for all departments, at any time.

I have the 'static' part figured out: there is a company controller, which returns an object with a departments property, with their IDs, descriptions, etc.

I am however confused about how to handle the historical data:

  • Should it be a part of the 'static' data? I would alter the department class with properties for the historical data. (And therefore, I would return the entire configuration every time new data is requested).

  • Shoud I create a parallel flow (new controller companyHistory, new class, etc. which returns only the ID of the departments and their history, and the binding is done in the UI?)

  • ...

I have little doubt that this has been studied before, and that there is a well-known pattern to handle such cases, but I have not been able to find any reference to it.

Could you point me to such a pattern?

Improve this question
0

As a first step, I'd question the staticness of department information. Truly unchanging organizational structures probably don't exist in companies that live for some time. Regarding your actual question, I don't offhand know of a specific pattern. The most useful solution might be an API that takes an optional timestamp parameter to show data (and possibly organizational structure) for that point in time, or current data if the parameter isn't given. Don't let the details of which part of the data is static creep into the client code, it makes things complicated and brittle.

Improve this answer
2
  • Thank you. I was hoping to avoid rebuilding the entire UI when the requested timestamp changed (ie. keep the 'static' parts, and update the fields for the historic data only). It may not be worth the trouble... – Maxime Jul 9 '18 at 6:00
  • That's a valid concern, not easy to answer without knowing the actual use cases and requirements. My main point was that you shouldn't needlessly limit the API because that is normally harder to change than the UI which may start out simple and be fleshed out later. – Hans-Martin Mosner Jul 9 '18 at 6:19
1

If your API is customer-facing, its design should be driven by product requirements, not the data model. Your particular requirements might not call for access to historical data at all (how useful would it be to know the history of a department's name?)

If it were to be exposed, I would imagine that the current department records would be needed much, much more than the historical ones, so you'd probably want to keep those lightweight and not burden them with carrying around their history every time a department is retrieved.

Improve this answer
1
  • It is the very purpose of the project, provide an interface to navigate historic records, so pretty useful :) – Maxime Jul 9 '18 at 5:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.