мне представляются таблицами на манер ассоциативного массива bash

Открой Calc – вот тебе столбцы и строки.

Пользовательская таблица состоит из столбца тегов, столбца с списком постов

Допустим.

каждый элемент которого состоит из id поста, момента времени когда пользователь этот тег добавил и флагов статуса поста

Видимо речь о no-SQL решении. Или мы будем хранить в полях таблицы кучки JSON-гавяшек?

состоит из отдельных субБД в котором каждая субБД посвящена одному тегу и состоит из столбца с id постов и столбца флагов поста в формате аналогичном формату флагов пользовательской таблицы

Ну давай для начала разжуём терминологию.

БД – она, как правило, одна на всё. Ибо нет смысла ради одного или кучки тегов держать отдельное хранилище.

Внутри БД лежат таблицы.

У таблиц есть поля.

SQL-запросы являются, именно что, запросами к движку БД, которые явно говорят, что нужно выбрать. Самый простой пример:

SELECT [список полей] FROM [имя таблицы] WHERE [условия выборки]

Если тебе нужно привязать более одного тега к одному посту, то классическим вариантом будет три таблицы типа (пишу в виде “таблица: поле1, поле2, полеN”) таких:

posts: id, title, body

tags: id, name

posts_tags: post_id, tag_id

Допустим, в таблицах лежат следующие данные:

posts:

1, ‘название поста’, ‘текст поста’

tags:

1, ‘тег1’ 2, ‘тег2’

posts_tags:

1, 1 1, 2

Чтобы сделать выборку всех тегов поста, используется джойн:

-- выбрать
SELECT

        -- поля из таблицы тегов
        tags.id,
        tags.name

    -- но начинаем тащить из таблицы постов
    FROM posts

    -- присоединяем таблицу связей постов и тегов, где айди поста наш
    LEFT JOIN posts_tags
        ON posts_tags.post_id = posts.id

    -- теперь присрединяем таблицу тегов, где теги наши судя по таблице связей
    LEFT JOIN tags
        ON tags.id = posts_tags.tag_id

    -- где нужный айди поста в таблице постов
    WHERE posts.id = 1;

(ну пиздец, подсветка не парсит комменты)

А вот теперь, уже лучше понимая, как это работает, повтори попытку проектирования.