Мы создаем мультитенантное приложение с гибкой организационной структурой, в которой
- Структура организации может иметь неограниченные уровни
- Структура организации может изменяться в любой момент времени
Я думаю, что основной структурой организации может быть таблица с самоссылкой, например так:
+-------+-------------+----------+
| OrgId | OrgName | ParentId |
+-------+-------------+----------+
| 1 | Runners | NULL |
+-------+-------------+----------+
| 2 | FastRunners | 1 |
+-------+-------------+----------+
Таблица версий, в которой структура может измениться в любой момент времени, FiscalYear Поле в основном просто позволяет будущим разработчикам легко запрашивать отчеты и тому подобное.Было бы правильно назвать это таблицей версий?или, может быть, Detail?:
+-----------+-----------+------------+------------+
| VersionId | ValidFrom | ValidTo | FiscalYear |
+-----------+-----------+------------+------------+
| 1 | 2019-1-14 | 2019-6-31 | 2018 |
+-----------+-----------+------------+------------+
| 2 | 2019-1-14 | 2019-6-31 | 2018 |
+-----------+-----------+------------+------------+
| 3 | 2019-7-1 | 9999-12-31 | 2019 |
+-----------+-----------+------------+------------+
| 4 | 2019-7-1 | 9999-12-31 | 2019 |
+-----------+-----------+------------+------------+
И таблица сопоставления, чтобы версия / деталь и основная таблица не были сильно связаны друг с другом для удобства вставки и обновления:
+-----------+-------+
| VersionId | OrgId |
+-----------+-------+
| 1 | 1 |
+-----------+-------+
| 2 | 2 |
+-----------+-------+
| 3 | 1 |
+-----------+-------+
| 4 | 2 |
+-----------+-------+
рекомендовать какие-либо изменения в этой структуре?Есть ли предупреждения против такой структуры?У меня нет большого опыта в самостоятельных ссылках на таблицы с гибкой организацией, поэтому любая помощь приветствуется.Спасибо!