PostgreSQL для BIM: зачем параметры держать вне Revit

Excel ломается на третьем проекте: версии путаются, история теряется. Разбираем, что даёт база под выгрузки параметров, во что обходится и когда не нужна.

Вопрос от руководителя BIM-отдела: «Покажи, как менялась заполненность параметров по объекту с апреля». Ответ занял два дня. Выгрузки лежали в Excel, файлы назывались экспорт_финал_2, экспорт_финал_2_испр, часть перезаписана поверх.

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

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

Где Excel перестаёт справляться

Таблица прекрасно работает на одном проекте и одном человеке. Ломается она предсказуемо, по четырём причинам.

Нет истории. Файл перезаписан, предыдущее состояние потеряно. Сравнить апрель с июнем нечем.

Нет ключа. Строка не привязана к элементу модели однозначно, потому что Id в Revit меняется при копировании, а GUID в выгрузку никто не включил.

Нет одновременной работы. Двое открыли, один сохранил, правки второго исчезли. К этому все привыкли и считают нормой.

Нет запросов. Ответить на «сколько элементов без марки в разделе ОВ на 15-м этаже» можно, но через десять минут ручных фильтров, и каждый раз заново.

База закрывает все четыре пункта. Не потому что модная, а потому что она для этого сделана.

Что кладём в базу, а что нет

Геометрию туда тащить не надо. Ни стены, ни трубы, ни солиды. Модель живёт в Revit и в IFC, база хранит про элементы факты.

Рабочий минимум таблиц:

create table elementy (
    guid          uuid primary key,          -- UniqueId из Revit, не ElementId
    proekt_id     int  references proekty(id),
    versiya_id    int  references versii(id), -- какая выгрузка
    kategoriya    text,                       -- Стены, Двери, Воздуховоды
    uroven        text,
    marka         text,
    obem          numeric(12,3)
);

create table parametry (
    guid          uuid,
    imya          text,      -- имя параметра как в модели
    znachenie     text,
    versiya_id    int
);

create index on parametry (versiya_id, imya);

Ключевая строка тут versiya_id. Каждая выгрузка пишется как новый срез, старое не затирается. Место это ест копейки: срез модели на 380 тысяч элементов занимает около 60 МБ, за год выгрузок набегает пара гигабайт.

Дальше вопросы к базе становятся однострочными:

-- заполненность обязательного параметра по разделам, последняя версия
select kategoriya,
       count(*) filter (where znachenie is null or znachenie = '') as pusto,
       count(*) as vsego
from elementy e join parametry p using (guid, versiya_id)
where p.imya = 'ADSK_Наименование' and e.versiya_id = 118
group by kategoriya order by pusto desc;

Тот самый вопрос про апрель и июнь решается сравнением двух versiya_id и занимает секунду вместо двух дней.

Что это даёт, кроме удобства

Динамика вместо снимка. Видно не «сейчас 640 пустых параметров», а «было 1900, за три недели стало 640, темп нормальный». Управленческий смысл появляется именно из динамики, об этом статья про дашборд.

Сравнение версий модели. Что добавилось, что исчезло, у чего изменилась марка. По GUID это честное сравнение, а не сверка двух таблиц глазами.

Проверки на стороне сервера. Правила качества описываются запросами и гоняются по расписанию. Модель никто не открывает, отчёт приходит утром сам.

Общий язык со сметой и снабжением. Объёмы отдаются выгрузкой из базы, а не пересылкой rvt-файла. Смежные отделы перестают просить «сделайте нам спецификацию в экселе» два раза в неделю.

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

Чем выгружать

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

Четыре грабли, на которые мы наступили

Взяли ElementId как ключ. Он уникален внутри файла и меняется при копировании элементов между моделями. История развалилась на второй выгрузке. Правильный ключ - UniqueId, он же GUID.

Выгружали всё подряд. Первая версия тащила 240 параметров с каждого элемента. Выгрузка модели занимала 50 минут, база пухла, пользы ноль. Оставили 18 параметров, которые кто-то реально смотрит, время упало до четырёх минут.

Забыли про кириллицу в именах. Параметр Марка и параметр марка с пробелом на конце в базе стали разными строками. Отчёт показал двойные цифры. Нормализация имён при записи решает вопрос за десять строк кода.

Держали базу на рабочей станции. Компьютер BIM-менеджера ушёл в перезагрузку, ночная проверка не отработала, никто не заметил три дня. База переехала на сервер в контейнере, о такой схеме есть отдельный разбор.

Где это не работает

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

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

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

И про безопасность. База с параметрами объекта это чувствительный документ. Открытый наружу порт PostgreSQL без пароля находят сканеры за сутки, проверено на чужом опыте.

С чего начинается первая неделя

Соблазн начать с проектирования красивой схемы на двадцать таблиц стоит подавить. Работающий вариант растёт с одной.

День первый: договориться о списке параметров. Собрать сметчика, снабженца и ведущего проектировщика, выписать, что кому нужно. Обычно набирается 15-18 позиций, а половину из первоначального списка вычёркивают сами.

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

День четвёртый: сделать три запроса, которые кто-то реально задаёт. Заполненность по разделам, список элементов без марки, сравнение с прошлой неделей.

День пятый: показать результат тому, кто просил цифры. Дальше решение принимается по его реакции. Если ответом будет «интересно», проект стоит остановить: интерес не окупает поддержку. Если «а можно то же самое по остальным объектам», можно продолжать.

Сколько стоит

Сервер под базу и сервисы: от 600 ₽ в месяц за виртуальную машину, которой хватает на несколько проектов. Сама PostgreSQL бесплатна.

Настройка контура с нуля: 2-4 недели работы разработчика вместе с выгрузкой и первым дашбордом. Дальше поддержка - несколько часов в месяц.

Экономия на нашем замере: сбор ежемесячного отчёта по восьми объектам занимал два дня, стал автоматическим. Плюс исчез класс вопросов «а какая версия правильная».

Короткие ответы

Почему PostgreSQL, а не MySQL или SQLite? SQLite подойдёт для одного человека, дальше упрётесь в одновременный доступ. Между PostgreSQL и MySQL разница для этой задачи невелика, мы берём первую из-за работы с JSON и оконных функций.

Нужен ли администратор баз данных? Нет. Одна база с парой таблиц и резервной копией по расписанию обслуживается BIM-специалистом после короткого обучения.

Можно ли писать в модель обратно из базы? Технически да, через Dynamo или плагин. Практически - осторожно и только по кнопке человека. Автоматическая запись в модель из внешнего источника это лучший способ испортить файл незаметно.

Что с готовыми платформами? Они закрывают часть задач и стоят денег за место. Своя база выигрывает, когда нужны нестандартные правила проверки и связка с внутренними системами.

Как быть с IFC от смежников? Парсить и складывать в те же таблицы. Тогда сводная картина по объекту собирается независимо от того, кто в чём проектирует.

Что дальше

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

Первый шаг обычно короткий: договориться о списке параметров, которые кому-то нужны. Обычно их меньше двадцати. Что мы делаем с данными и инфраструктурой, описано в услугах, примеры задач - в кейсах. Задачу можно описать в Telegram или через контакты.