Почти у всех системных таблиц есть поле "DESCRIPTION BLOB SUB_TYPE 1 CHARACTER SET UNICODE_FSS". Но кроме описания имхо было бы удобно иметь возможность хранить и другую инфу, ту которая нужна разработчику БД.

Короче хочется кой-чего похранить для таблиц, вьюх, полей, триггеров, индексов, процедур и функций (+их аргументов), UDF, доменов, констрейнтов. Ещё возможно для ролей, привилегий пользователя, да и для самих пользователей (пользователей вроде можно будет в тройке хранить прям в базе, если я ничего не путаю).

Хотя вот сейчас подумал ещё... Ещё более удобно было бы добавлять поля к этим системным таблицам ALTER-ом, и работать с этими полями как с обычными. Это было бы ещё правильней, с точки зрения разработчика БД :)

Проверил через IBExpert - блин, а ведь можно добавить поле к системной таблице :)
Добавил поле:


IBExpert предложил ввести значение , т.к. поле NOT NULL. Сначала я ввёл 1, а потом, при следующей попытке (после неудачного B/R (см.ниже)), я ввёл GEN_ID(GEN_RELATION_ID, 1).
Ок. Получил возможность ссылаться на таблицу по ID.

Дальше выполняю:

Ок.

Дальше выполняю:

Ok.

Дальше выполняю:

This operation is not defined for system tables.
unsuccessful metadata update.
STORE RDB$RELATIONS failed.
validation error for column ID, value "*** null ***".

Ещё я попробовал сделать B/R этой базы. Поле ID пропало из RDB$RELATIONS.
А счастье было так близко... :)

Было бы удобно, если бы пользовательские поля переживали B/R как и RDB$DESCRIPTION.
Ну и чтобы триггеры таки срабатывали :)
Это я на 2.5 экспериментировал.

А если идти ещё дальше, то я бы не отказался от возможности сделать так:
Создаём в RDB$RELATIONS поле IS_LOGGED BOOLEAN NOT NULL DEFAULT FALSE, и поле ID из примера выше.
Изменение значения поля IS_LOGGED ловим в триггере на update:

Ok.

процедурка TURN_LOG_FOR_TABLE создаст (или удалит) триггеры для логирования изменений данных в табличке с указанным ID.
Т.е при


и после коммита, мы получаем логирование для всех несистемных таблиц.
И после B/R хочется чтобы ничего не поломалось :)
Также для нужд логирования я бы хотел создать поля ID, RELATION_ID и IS_LOGGED в табличке RDB$RELATION_FIELDS, и написать триггер, отлавливающий изменение поля IS_LOGGED и типа(вдруг кто ALTER-ом тип поля изменит). В этом триггере пересоздавал бы при необходимости триггеры логирования.
И триггер на удаление для RDB$RELATION_FIELDS тоже потребуется, чтобы исключить поле из триггеров на логирование (если таблица логируется и если у текущего поля IS_LOGGED = TRUE).

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

Я бы с удовольствием добавил бы несколько полей в RDB$DATABASE, для глобальных настроек БД :) Имхо им там самое место :)
Точно добавил бы поля в таблицу с пользователями (там самое место для хранения их персональных настроек), добавил бы туда ID, добавил бы IS_OLD BOOLEAN (Типа сотрудник уволился, а ссылки на него в документах остались. Логиниться он не может, и отображать его в справочнике пользователей смысла нет).
Вообще я бы добавлял во все таблицы-справочники поле IS_OLD BOOLEAN, и сделал бы это с помощью триггера, обрабатывающего изменение поля IS_DICTIONARY в RDB$RELATIONS :) Т.е. поставил в IBExpert галку в поле IS_DICTIONARY для соответствующей таблицы, и у этой таблицы сразу поле IS_OLD добавилось (и поле NAME VARCHAR(n)). Нажал галку IS_TREE_DICTIONARY, и у таблицы создалось в добавок поле PARENT_ID :) Нажал галку HAS_MANUAL_ORDER, и у таблицы появилось поле RECORD_ORDER.
Настраивать можно прям не выходя из IBExpert.

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

dimitrзабудь
Хочешь сказать, что на данном этапе это не вписывается в твои понимания о добре и зле архитектуру? :)

kdvNickDeeПоле ID пропало из RDB$RELATIONS.
понимаешь, почему пропало?
Я думаю что просто не реализован такой функционал.
Для поля RDB$DESCRIPTION он реализован, а для ID - нет.
Думаю причина в этом. Ничего вроде не мешает эти поля так же создавать и восстанавливать в них значения.

Я ещё попробую это (логирование) на уровне DDL триггеров и отдельных (связанных с RDB$*) таблиц сделать.
Т.е. на уровне DDL тригеров нужно будет при добавлении таблицы автоматом создать запись в Ext$Relations (Id, TableName, IsLogged), и создать записи в Ext$RelationFields (Id, TableId, FieldName, IsLogged). Так же нужно будет отлавливать ALTER TABLE T на предмет изменения названия полей, типов, удаления полей. И нужно будет сопоставлять распарсенное с тем, что уже есть в базе (чтобы например при изменении имени поля проапдейтить соответствующую запись в Ext$RelationFields).

А в DDL-триггере (интересен BEFORE) вообще можно создавать или дропать триггеры, таблицы, изменять данные существующих таблиц?

Вот прям хочется получить удобно-настраиваемое (например из IBExpert) логирование :) Создал табличку, ткнул галочку напротив имени таблички в Ext$Relations - получил логирование :) Что ещё может быть удобней? :)
Есть ещё удобней - это если бы не пришлось городить отдельную табличку, а IBExpert сам бы мог из RDB$RELATION_FIELDS поднимать несистемные поля и давать их редактировать пользователю :) А несистемные поля из RDB$RELATION_FIELDS размещал бы прям в гриде где список полей таблицы отображается (т.е. окно где мы поля добавляем в таблицу) - создал поле, поставил галку IsLogged (галка прописалась в RDB$RELATION_FIELDS, там сработал триггер, который пересоздал триггеры логирования), и всё.
Да, это было бы ещё удобней :)

Симонов ДенисNickDee,

в тройке как раз наоборот вроде думают запретить правку системных таблиц
Запретить править системные поля системных таблиц - это очень и очень правильно. Но RDB$DESCRIPTION вот добавили, и разрешили менять отдельным sql-стэйтментом.
Ну ещё можно добавить полей, а изменять их уже через sql. А системные сделать read-only. Это вопрос по-моему вторичный - чем менять :)
И добавлять поля можно разрешить не во все таблицы, а только в те, которые не меняются сами по себе (я про MON$).

kdvNickDeeЯ думаю что просто не реализован такой функционал.
не думаешь. база данных всегда создается с готовым набором системных таблиц. Собственно, можно сказать что "болванка" БД вшита в сервер.
Вот когда мы делаем рестор, то в случае обычных таблиц там делается CREATE TABLE, а потом переливаются данные через insert.
А в случае системных таблиц можно сделать ALTER TABLE, и так же перелить данные, но уже через update.
Имхо это вопрос воли :)

Кстати в fb-devel видел обсуждение синтаксиса добавления именованных атрибутов к пользователю.
И так и не понял, чем плохо добавлять атрибуты обычным alter table, и потом менять их через update, и селектить селектом?
Зачем придумывать отдельный синтаксис для создания, удаления, обновления, и селекта атрибутов? И ещё сами атрибуты получаются нетипизированные. И констрейнтов не навесить. И права не раздать. И в IBExpert не посмотреть через просмотр таблицы sec$users.