Прежде всего, я предполагаю, что вы хорошо понимаете что такое Notion. Вероятно, так или иначе, у вас некоторый пользовательский опыт и здорово, если вы среди тех, кто пользуется Notion на постоянной основе, как мощнейшей системы хранения данных и управления важными для вас процессами.

Прежде чем раскрыть тему, я представлюсь так как это первый мой пост в сообществе Хабр.
Можете смело пропустить этот абзац, если моя личность вам не интересна. Меня зовут Sasha Geo, я основатель и прошлом 18 лет управляющий известным ресурсом geometria.ru. Последние 3 года не имею к нему никакого отношения в силу разных негативных обстоятельств.

В настоящее время я Notion эксперт, 2 года веду продвинутый курс по созданию систем управления в Notion и разрабатываю решения на платформе Notion для сторонних клиентов.

Теперь по теме.

Синонимом бинарной системы является двухсторонний self-relation, особенность которого в образовании родительской записи по отношению к зависимой с ней.

Но, между бинарной системой и просто 2-х не бинарных self-relation есть огромная разница.

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

Я уверен, что с точки зрения понимания логики как это работает большинство пользователей Notion для того, чтобы создать в базе данных возможность связи записи А с записью Б создадут просто self-relation, а когда нужно чтобы Б, также был связан с C они будут использовать тот же self-relation, либо создадут еще один, если такая связь должна быть в отдельном пропертис (свойство или ячейка базы данных).

Односторонние связи в базе данных работают линейно и лишены логических проблем восприятия бинарного эффекта, возникающего в момент образования бинарной связи одной записи с другой.

Как мы видим на гифке, новая запись была связана с другой записью, по смыслу являющейся родительской, в данном случае "Notion", но по отношению к самому "Notion", она же является связанной (если отталкиваться от обозначения в пропертис).

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

Несмотря на то, что по данным пропертис практически не понять, почему отдельный факт является группой по отношению к записи "Иван Чжао", на дешборде данной записи, все выглядит структурировано.

Именно поэтому в использовании системы хранения данных типа Zettelkasten я полагаюсь не на пропертис, а именно на удобно структурированные дешборды записей базы данных, которые распределяются по тематическим блокам автоматически после применения соответствующего шаблона базы данных.

Под каждый тип записи в базе создаются соответствующие шаблоны, включающие в себя такие блоки как:

• Название

• Люди

• Факты

• Статьи

• Цитаты

• Файлы

• Линки

• и т.п.

  В конечном итоге это позволяет переходить от записи в запись с высокой эффективностью пополнить багаж знаний или напротив дополнить их.

  Как вы, наверное, догадываетесь настройка шаблонов — это самое сложное. Но есть 2 простых приема, комбинация которыми позволяет достичь нужного результата в настройках фильтрации данных.

  Фактически, в моем цеттелькастен есть 2 параметра, которые влияют на фильтрацию данных общей базы. Сама система состоит из 2-х баз данных:

• Направления

• База знаний

База направлений существует лишь для одной большой цели — собирать статистические данные и второй вспомогательной — являться директориями реестров данных.

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

В качестве инструментов, позволяющих создавать точную настройку блоков данных выступают:

• название self-relation (данные так или иначе связаны либо с групповым (родительский релейшн) либо с дочерним). Правда есть еще один селфрелейшн, выполняющий функцию авто фильтрации всех блоков шаблона по названию записи в базе. В моем случае он называется "название".

• тип записи

По сути, это 2 основных параметра, комбинация которыми позволяет выводить определенные данные из общей базы в нужных местах.

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

С одной стороны, если данные вводятся непосредственно на дешборде записи, где контент блоки уже заранее отфильтрованы, ты получаешь результат и он тебя устраивает так как ты видишь данные на своих местах. Но все по-другому, когда те же данные ты пытаешься линковать на странице базы, образовывая связи записи с соответствующими ей группами и прочими записями. Здесь часто возникают ошибки, так как легко перепутать в каком статусе по отношению к записи будет запись и ее релейшен. Но если попрактиковаться, то все выстраивается достаточно просто.

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

Тот же принцип надо применять, если запись в базу осуществляется со страницы самой базы.

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

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

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

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

Надеюсь мне удалось раскрыть тему и показать специфику настройки шаблонов различных типов записи в базе Notion, используемой для системы Zettelkasten.