Следует ли разделять статические и исторические данные в API? В какой степени?

Проект предназначен только для чтения для базы данных компании.

В базе данных есть некоторые «статические» данные об отделах в таблице Departments. Значение этих полей не изменяется со временем (например, DepartmentID, DepartmentName, DepartmentDescription, HistoryTableName и т. д.).

Есть также некоторые данные с метками времени. Исторические данные для каждого отдела хранятся в отдельной таблице (с именем HistoryTableName, с такими полями, как timestamp, numberOfEmployees, Energy Consumption, ...). Как вы можете догадаться, макет данных не является чем-то, что может быть изменено в этой области.

Смысл интерфейса - иметь возможность доступа к данным для всех отделов в любое время.

У меня есть «статическая» часть: есть контроллер company, который возвращает объект с departments со своими идентификаторами, описаниями и т. Д.

Однако я не совсем понимаю, как обращаться с историческими данными:

  • Должна ли она быть частью "статических" данных? Я бы изменил класс department со свойствами для исторических данных. (И поэтому я бы возвращал всю конфигурацию каждый раз, когда запрашиваются новые данные).

  • Должен ли я создать параллельный поток (новый контроллер companyHistory, новый класс и т. д., который возвращает только идентификатор отделы и их история, а привязка осуществляется в пользовательском интерфейсе?)

  • ...

У меня мало сомнений в том, что это было изучено ранее, и что существует хорошо известная схема обработки таких случаев, но я не смог найти никакой ссылки на нее.

Не могли бы вы указать мне на такой шаблон?

1 голос | спросил Maxime 8 J000000Sunday18 2018, 19:54:15

2 ответа


0

В качестве первого шага я бы поставил под сомнение статичность информации отдела. По-настоящему неизменных организационных структур, вероятно, не существует в компаниях, которые живут некоторое время. Что касается вашего фактического вопроса, я не знаю ничего конкретного. Наиболее полезным решением может быть API, который принимает необязательный параметр метки времени для отображения данных (и, возможно, организационной структуры) для этого момента времени, или текущие данные, если параметр не указан. Не позволяйте деталям того, какая часть данных статически заползает в клиентский код, это усложняет и делает их хрупкими.

ответил Hans-Martin Mosner 9 J000000Monday18 2018, 01:30:53
1

Если ваш API ориентирован на клиента, его дизайн должен определяться требованиями к продукту, а не моделью данных. Ваши конкретные требования могут вообще не требовать доступа к историческим данным (насколько полезно было бы знать историю названия отдела?)

Если бы это было разоблачено, я бы предположил, что текущие записи отдела понадобятся намного, намного больше, чем исторические, так что вы, вероятно, захотите сохранить их в легком весе и не обременять их ношением своей истории каждый время, когда отдел извлекается.

ответил John Wu 9 J000000Monday18 2018, 02:18:47

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132