наглядно показано, почему мы точно не станем северной кореей. особено в конце познаавательно. когда гарницы европы перекраиваются, а глыба справа стоит монолитом

хочу посмотреть этот ролик через 10 лет

да и с европой, без англии можно считать что и страна, европа, уже одна.

куда подключиться?

анонс тут будет

за 5-10 минут

четверг 19-00

через зум

Что я только что прочитал

Прям особый путь завезли и отдельную цивилизацию

В этот четверг (28.05) в 19-00MSK состоится доклад " Context - библиотека управления состоянием системы в Clojure."

При создании новой системы разработчикам необходимо решить, каким образом они будут управлять состоянием ( state) системы. Для этого уже есть несколько устоявшихся подходов в виде библиотек mount, component.
Библиотека context предлагает еще один способ управления состоянием системы, в более простой форме.

Докладчик: Михаил Ананьев @mike_ananev

Ссылка на Zoom появиться за 5 минут до встречи.

печенегов забыли

И половцев

Знаю, что не по адресу. Но наверняка тут многие пользуются postgres.

Есть проблема. Хочется хранить вложенные данные рядом. Т.е. не нормализованно по табличкам, а рядом. И искать с индексами.
Есть jsonb, с индексами и json path. НО.
1) jsonb для динамических данных. Тут речь же о данных, имеющих схему и типы.
2) jsonb хранит ключи каждый раз. В итоге по большей части хранятся имена ключей, а не данные.
3) jsonb пока не умеет даты/время. Он точно не будет поддерживать постгресовые типы и индексы. Например диапазоны, гео точки.
 
Есть подход, применяемый в elastci search, когда данные делают плоскими и хранят каждую колонку как массив.
Еще так делает, например click house.
https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html#nested-arrays-flattening-objects
https://clickhouse.tech/docs/ru/sql-reference/data-types/nested-data-structures/nested/

т.е post.translation.title string[], post.translation.content text[]. Т.е. данные транспонируют или уплощают.
Тут есть особенности, если так делать с документом, то будут теряться связи, но если использовать реляции, то все ок.
Таким образом можно встраивать вложенные таблицы.
1) Будут доступны миграции, можно добавить/удалить/изменить колонку
2) Можно строить gin/gist индексы, можно делать фкнциональные индексы
3) Есть схема с привычными типами. Названия полей не пишутся каждый раз.
4) Да, при поиске будет теряться связь между вложенными таблицами, но это такая цена подхода, и если это неприемлемо, то нужно использовать обычные таблички

Кто что думает?

Кто как нормализует app-db в re-frame? В доках предлагают 3 библиотеки: compound, subGraph, pull.

Или есть у вас свои подходы?

какую задачу-то хочешь решить.? :)

Я делаю новую версию проекта для книжки app-from-scratch.
Мои сущности будут храниться как datascript структуры.
Т.е. Новость и перевод - это 2 типа сущностей. Но представлены они одной datascript структурой.
И я рассматриваю варианты как это хрранить в постгресе.
Первое и очевидное - разложить по табличками.
Но есть еще идея с массивами. Так не нужно делать дорогой join.
Понятно, что все это нужно тестировать на реальных данных. И все зависит от этих данных.
У меня тут более общая задача - собрать возможные подходы и понять их плюсы/минусы.

Это типа nested sets уже не модно?

?
у меня не одна datascript db на приложение, а много на каждый агрегат