This is not “simple”. On one side you have a Python expression involving a complex object called a dictionary. This data object is implemented (in memory) with hashing tables, a heap and various pointers. In short it is a “dynamic” mix of an algorithm + data. On the other side, a database is a way to store “statically” data in the long term. Data is recorded on disk in an elementary form which is described conceptually as columns (an array of identically typed basic data – numbers, strings or sometimes dates) in a table (a collection of columns where each row is a record).
As you see, there is no pointer within the basic data, with the consequence that no abstract data type, like a tree or “dictionary” is possible. There is even no array, making it impossible to store “naively” a list. However, workarounds allow to store any data architecture in a DB, thanks to the powerful and efficient query feature in the DB engine.
For example, contents of a list will be stored in a separate TABLE where each element consists of an id (a key) and the other columns making the element value. All members of the list share the same key. A different list uses a different key. In the “main” table, the column supposed to be list-valued contains the key specific to the list.
To retrieve the list, you query the DB on the “list table” with the key. You then get a collection of records = all members of the list.
You must understand that DBs and programs in any languages live in different “worlds”. You must translate concepts of one world into concepts in the other world. It is your programmer’s responsibility. In many languages, designers have proposed library to simplify the job. There are even “frameworks” with generic interfaces to DBs, but being generic and 'universal" they need to be understood mastered first.
There is also a quick “solution” avoiding the need to translate your abstract objects: BLOB (binary large object). A BLOB is yet another basic data in DBs. It was originally provided to store data which are neither numbers nor strings (think of images). The DB engine makes no assumption about what is inside (and therefore doesn’t try to optimise either for storage nor speed). Consequently, you can store directly any Python object in such a column. However, there is an important caveat: internally a Python object uses hardware pointers to manage its structure. You can’t store pointers, even in binary form, in a DB because the object will never be reloaded at the exact same address as where it was created. Consequently a Python object must be serialised (is “pickled” the Python term?) before being stored into the DB and unserialised on reload. This again must be done by yourself.
Anyway, using Base, you can’t spare the task of describing your data in a schema. This schema is written in SQL language. There are slight variations in SQL depending on the backend. After organising your data storage, you have to write queries. Each query addresses a particular aspect of your data. Some queries can be relatively complex likes ones retrieving records which contains lists or other high-level sub-records.
