@prochanev

Как хранить схемы диалогов для чат-бота?

Добрый день!
Подскажите, пожалуйста, как и в какой бд (РСУБД или NoSQL) хранить схемы для множества чат-ботов. Под схемой я подразумеваю граф диалога, взаимосвязи между опциями и следующими/предыдущими сообщениями. Ну т.е. заранее сконструировали диалог для бота и запустили, таких ботов/диалогов может быть много.

В первом приближении, я подумал, что нормальным вариантом будет поле типа JSON в Postgreql с примерно таким содержимым:

{
   1:{
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":2
      },
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":3
      },
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":4
      }
   },
   2:{
      "answer1":{
         "text":"blah blah",
         "photo":"picture.jpg",
         "to":5
      }
   }
}


А таблица с ботом примерно такая
bot_id | description | token_hash | schema(вот про это поле я и говорю)

Т.е. много разных ботов с разными диалогами.

Но напрягает, что при взаимодействии с таким ботом придется раскручивать всю эту структуру, как будто контроль теряется. + я не уверен, как ORM работает с полем JSON.

Подскажите, пожалуйста, кукую бд и схему хранения данных лучше выбрать?
Приму любые мысли, критику, да что угодно :)
  • Вопрос задан
  • 80 просмотров
Решения вопроса 2
trapwalker
@trapwalker Куратор тега Python
Программист, энтузиаст
Нормально ORM работает с JSON, но не понятно зачем вам именно реляционная БД, если вы фактически отказались от нормализации и джойнов.
Для вашего этого варианта подойдёт и NoSQL.
таких ботов/диалогов может быть много.

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

Отрефакторить преждевременно оптимизированное решение будет гораздо сложнее, чем простое.
Практика показывает, что в ходе реализации MVP часто вылезают новые требования, которые заставят вас усложнять модель. Простое мнималистичное решение позволит более гибко добавлять функциональность и не потерять бестолку время на написание сложного кода. который всё ранво переписывать.

В вашем случае можно сделать всё на ORM и реляционной базе. Включая отдельные модели для вариантов ответов и прочего.
Можно отказаться от ORM и размещать одного бота в одном документе. Тогда можно использовать монгу и десериализацию документа в собственную структуру классов. Тут писать получится больше, но и гибкость будет выше, можно будет пользовтаельские плагины какие-то прикручивать... вопрос - надо ли это и понадобится ли в будущем?

Фактически диалог - это конечный автомат. Его можно представить в виде графа. Человечество уже давно придумало много способов сохранять и оперировать графом в любой БД, в том числе реляционной.
Ответ написан
alternativshik
@alternativshik
Мы в Монге хранили весь JSON со сценарием диалога. Сначала начинали на Постргресе делать, но потом это оказалось дольше и не так удобно на этапе MVP, потому засунули в монгу + фронт для создания этого сценария создавал весь этот JSON, который можно было просто и быстро провалидировать и дальше пользоваться.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы