How to store dialogue schemes for a chatbot?

Question

Python

Good afternoon!
Please tell me how and in which database (RDBMS or NoSQL) to store schemas for many chatbots. By schema, I mean the dialogue graph, the relationships between options and next/previous messages. Well, i.e. pre-designed a dialogue for the bot and launched it, there can be many such bots / dialogues.

As a first approximation, I thought that a JSON type field in Postgreql with something like this would be a normal option:

{
   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
      }
   }
}

And the table with the bot is something like this

bot_id | description | token_hash | schema(вот про это поле я и говорю)

Those. many different bots with different dialogues.

But it’s annoying that when interacting with such a bot, you will have to unwind this entire structure, as if control is lost. + I'm not sure how the ORM works with the JSON field.

Tell me, please, which database and data storage scheme is better to choose?
I welcome any thoughts, criticism, whatever :)

Answer 1

Normally, ORM works with JSON, but it’s not clear why you need a relational database if you actually abandoned normalization and joins.
For your this option, NoSQL is also suitable.

there can be many such bots/dialogs.

A lot is a loose concept. Have you already encountered some kind of bottleneck and want to optimize something already? If not, then do as simple and clear as possible within the framework of functional requirements.
Refactoring a prematurely optimized solution will be much more difficult than a simple one.
Practice shows that during the implementation of MVP, new requirements often come out that will force you to complicate the model. A simple minimalistic solution will allow you to add functionality more flexibly and not waste time writing complex code. which is too early to rewrite.
In your case, you can do everything on an ORM and a relational database. Including separate models for answer options and more.
It is possible to refuse ORM and place one bot in one document. Then you can use mongo and deserialize the document into your own class structure. There will be more writing here, but the flexibility will also be higher, it will be possible to screw in some custom plug-ins ... the question is - is this necessary and will it be needed in the future?
In fact, the dialogue is a state machine. It can be represented as a graph. Mankind has long come up with many ways to save and operate a graph in any database, including a relational one.