F # - Как эффективно хранить и загружать DU / записи деревьев в базе данных - PullRequest
0 голосов
/ 30 декабря 2018

Я моделирую бизнес-домен, используя F # DU / деревья записей.Он работает как шарм и делает то, что должен делать.Типичная глубина дерева составляет около 2-5.Теперь мне нужно сохранить некоторые параметры (давайте назовем их settings) в базе данных, а затем загрузить их при запуске.Количество настроек составляет порядка 100. Мне также нужна возможность редактировать отдельные настройки в SQL, что означает, что сериализация всего дерева в JSON или что-то подобное выглядит неудобно.

Однако бизнес-сферажидкость на текущем этапе.Это означает, что деревья могут и будут «перебалансированы».Это означает, что некоторые параметры будут перемещены здесь и там и / или переименованы / добавлены / удалены.Что также означает, что моделирование объектов F # в SQL напрямую (F # тип X -> таблица SQL X) удвоит (если не больше) время разработки.

Одной из альтернатив является создание «общей могилы», которая представляет собой таблицу, в которой хранятся все настройки, а затем используется длинный ключ строки, составленный из частей дерева (например, object1.object2.object3…), длячтобы получить конкретную настройку.

Интересно, есть ли лучшее решение?Большое спасибо!

1 Ответ

0 голосов
/ 30 декабря 2018

По сути, вам необходимо изолировать свой домен от любой схемы или механизма постоянства.Это никогда не делается «магией», а скорее (отображением) кода, который вы пишете и поддерживаете.

Так что сохраняйте домен как домен (никогда не думайте о постоянстве здесь) и рассматривайте постоянство как отдельную проблему.

Если, как вы указали в вопросе, важно иметь возможность устанавливать индивидуальные настройки вручную в БД, тогда совершенно плоская схема - это то, что нужно делать.Затем напишите маперы Domain -> DB и DB -> Domain.

...