т.н. «шторки» — фильтры комментариев для отдельных сообществ.
хранится ид отфильтрованной ветки; ид журнала, для которого наложен фильтр; и модератор, сделавший это

5. npj_comments_replicas

вспомогательная таблица для учёта реплицированных комментариев

6. npj_csa

таблица для хранения временных ключей межузловой авторизации

7. npj_groups

«отношения между пользователями»: группы. Например, «все друзья этого пользователя».
у каждого аккаунта (пользователя, РГ) может быть произвольное число таких «групп», куда попадают другие пользователи, с которыми у него есть отношения.
есть системные группы is_system=1, которые нельзя удалить руками их владельца. Например «все конфиденты».
есть метасистемные группы is_system=2..4 — они используются, чтобы при создании нового аккаунта какого-то типа, создать нужный ассортимент системных групп. =2 — для пользователя, =4 — для РГ.
user_id — к какому аккаунту относится эта группа
group_rank — уровень группы. Если группа рангом 2, то все её члены как бы «входят» во все группы ранга 1. Обратите внимание, как устроены системные группы «члены/модераторы»
group_type — не используется нигде.

8. npj_links

таблица перекрёстных ссылок между записями, существует для action Backlinks.

9. npj_maildebug

таблица для складывания в неё входящих на узел писем, которые не удалось распознать как команды на создание/редактирование записей/комментариев

10. npj_nodes

таблица с актуальным перечнем узлов НПЖСети.
если узел не Npj Name Server, то содержимое этой таблицы будет перезаписываться при каждом получении обновления с NNS.
is_local — это ваш узел!

11. npj_npz

* таблица заданий для Http Cron. learn more at

http://wackowiki.com/htcron

12. npj_profiles

* здесь хранятся «профили» аккаунтов. Т.е. та информация, которая является «описательной» (дополнительной) для журналов пользователей/сообществ.
* lft_id, rgt_id — пока не используются
* *_template — пока не используется
* *_membership — группа какого ранга имеет соответствующие права?
* last_updated — пока не поддерживается
* email_confirm — если пустой, то емайл подтверждён. Иначе — шифр подтверждения

13. npj_record_versions

здесь хранятся «версии» записей — их устаревшие тексты. При редактировании записи старое её состояние записывается сюда, и используется при диффах.

14. npj_records

очень важная таблица, в которой хранятся записи (сообщения и документы, они же категории)
user_id — в каком журнале запись, author_id — кто написал запись. Всё это не имеет отношения к публикации сообщений в сообщества
*_r, *_post — разные степени отформатированности текстов. *_r показывается при отображении записи (и ещё доформатируется), *_post используется для сборки лент
default_show_parameter — фактически obsolete
group_1..4 — какие «группы доступа» (из таблицы npj_groups) установлены для записи. Если все нули — запись публична. Кроме этого, есть специальные комбинации для «приватной записи», «записи для всех конфидентов», «записи с доступом только в сообщества» и «записи для глобальной группы доступа».
keywords/crossposted — отформатированная строка про то, куда опубликована запись. Используется для того, чтобы показываться в ленте сообщений. Не для определения, куда опубликовано.

15. npj_records_rare

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

16. npj_records_ref

вторая очень важная таблица, обычно называемая «рефы». В ней хранятся связи «запись такая-то опубликована туда-то».
таблица используется для выборки страницы ленты (в т.н. «суперзапросе»)
публикация в сообщество здесь ничем существенным не отличается от публикации в рубрику.
owner_id — в каком журнале запись, keyword_id — какая рубрика (ид из таблицы записей), keyword_user_id — в каком журнале эта рубрика
syndicate — флаг, позволяющий в этой таблице понимать, нужно ли забирать эту запись при сборке ленты
priority — глубина транзитивного замыкания, которое производится при публикации в подрубрику (в этом случае в рефы пишутся строки о а) публикации в журнал, б) публикации в надрубрику и в) публикации в подрубрику — с разным приоритетом, что позволяет потом не собирать дубли).

17. npj_records_ref_rules

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

18. npj_records_replicas

информация о реплицированных сообщениях (из записей реплицируются только сообщения)

19. npj_replica_dest_rules

правила репликации, для пункта назначения

20. npj_replica_dests

пункты назначения (приёмки) реплицируемых данных

21. npj_replica_queue

очередь на репликацию

22. npj_replica_rules

правила репликации для пунктов отправки

23. npj_subscription

здесь хранятся данные о том, кто на что подписался по электронной почте.
где-то в node@npj:tree есть даже описание формата.

24. npj_usage_stats

внутренняя статистика, какие методы запрашиваются и кем. По-умолчанию отключена, на узле npj.ru отключена после запуска в публичное использование.

25. npj_user_groups

«отношения между пользователями»: с кем связан пользователь.
раньше были «группы» (не РГ!), теперь кто в них входит.
group_id — это про таблицу npj_groups
user_id — это какой пользователь является, например, «моим другом».
keyword_id — для ускорения выборок и возможности подписаться на подрубрику в «корреспонденты»

26. npj_user_menu

это меню ссылок пользователя, которое есть в minikui, criba, crabla, academic.
мелкая, вспомогательная табличка

27. npj_userpics

здесь хранятся отметки о том, какие у пользователя юзерпики. Сами юзерпики хранятся в файловой системе

28. npj_users

и последняя важная таблица, в которой хранятся аккаунты пользователей, а также сообществ и РГ
account_type — собственно, определяет, пользователь или РГ
account_class — см. «Классы аккаунтов» (где-то в node::tree есть документация)
owner_user_id — кто создал этот аккаунт (очень полезно для сообществ, иногда интересно для пользователей)
domain_type — поле, позволяющее работать с адресами вида kuso.npj.ru
__roles — obsolete поле, унаследованное из CMS
original_user_id — если этот аккаунт пришёл к нам с другого узла, то его id на том узле не тот, что на этом. Оригинальный (т.е. с того узла) ид мы храним в этом поле
root_record_id — запись, которая является «корневой» (адрес которой равен login@npj:, таг которой пуст)

NPJ next: Документация/УстройствоБД ...

Устройство БД

Вот список таблиц в БД с пояснениями

1. npj_acls

2. npj_ban_ip

3. npj_comments

4. npj_comments_filtered