Модераторы: m0p3e, edward_K, Модераторы
Код: Выделить всё
Категорически не рекомендуется пользователям использовать alter dictionary, т.к. при этом летит КС словаря. Соответственно, становится невозможен контроль соответствия приложения и БД. Отсюда возможны (и были реально) крупные неприятности. Теоретически - вплоть до полной потери БД.
Нашел тутМодификация словаря
Модификация словаря бывает прикладная - в обновления поставляются скрипты, которые надо запускать, и пользовательская - клиент сам решает, как ему нужно доработать стандартный словарь.
Пользовательская модификация словаря осуществляется простым запуском соответствующих запросов (create table, alter table etc), без оператора alter dictionary и параметра FullSQL. Или, что лучше для дизайнирования, из модуля Support-Консоль управления. При этом контрольная сумма остаётся такой же, какой была до этой модификации, т.е. пользовательские изменения словаря в расчёте контрольной сумме не учитываются. Занулять контрольную сумму словаря не надо.
С помощью пользовательской модификации можно не только создавать и изменять свои таблицы, но и:
- добавлять поля в конец стандартных таблиц;
- добавлять индексы к стандартным таблицам;
- добавлять сегменты индексов стандартных таблиц;
- удалять индексы стандартных таблиц;
- возможно (давно не проверял), удалять сегменты индексов стандартных таблиц.
Другие изменения структуры (полей, индексов) стандартных таблиц невозможны. Однако можно менять ссылочную целостность (как декларативную, так и ограничивающую) - к структуре она не относится.
Что даёт добавление полей, очевидно. Например - отказ от внешних атрибутов-классификаторов, что позволяет более просто и качественно добавлять свою логику. Но это более интересно программистам.
Манипуляции же с индексами более интересны администраторам. С одной стороны на поддержку индексов СУБД тратит определённые ресурсы. Чем больше индексов, тем больше БД, тем медленнее модификация, тем (на блокировочных СУБД) чаще конфликты изменений. С другой стороны - чем больше нужных индексов, тем быстрее поиск, да и сортировка работает.
Неиспользуемые индексы можно удалить (встаёт вопрос, как узнать о неиспользуемом индексе, но это тема для отдельного обсуждения). Используемые индексы можно доработать. Например, удалить неиспользуемые сегменты (тут, очевидно, вопрос тот же, только более сложного уровня). Более интересно - добавить свои сегменты в используемый индекс. Это может дать, например, более быстрый поиск в наложенных ограничениях, или автоматическую сортировку там, где её не предусмотрел разработчик. Наконец, добавление своего индекса часто оправдано при собственных доработках.
Пользовательскую докомпиляцию можно выполнять как из лицензируемых Support-Консоль управления (тут доступно GUI по изменению словаря), Support-SQL, так и из нелицензируемого (но штатно обновляемого!) консольного asql.
Для справки. Ограничения пользовательской докомпиляции не связаны с лицензионными или иными подобными ограничениями. Они связаны лишь с поддержкой корректности функционирования системы. Т.е., если вы хотите разломать свою систему, смело используйте alter dictionary & FullSQL. К сожалению, наши условия абонентского обслуживания несовершенны, и мы в любом случае будем пытаться разобраться в поломанной вами же базе.
Примечание. Известный хинт с занулением контрольной суммы связан с тем, что на Атлантисе 3.?? флаг пользовательского изменения словаря при расчёте контрольной суммы не учитывался. Он взводился, при самом изменении контрольная сумма не рассчитывалась, но при любом пересчёте она съезжала. Эта недоработка давным давно устранена.
Широко применяемая пользователями ошибочная практика alter dictionary & FullSQL связана, очевидно, с тем, что давным давно, когда часто происходила прикладная докомпиляция БД, пользователи, желающие выполнить пользовательскую докомпиляцию, предпочитали изучению документации смотреть исходники прикладной докомпиляции и делать так же, как там, не утруждая себя пониманием того, что же они делают.
Итого: забудьте про зануление контрольных сумм, alter dictionary и FullSQL - это инструменты для настоящих профессионалов (ака прикладные программисты), хехe
Вот это "ХЕХЕ" меня более всего добило. Не пойму до сих пор что это значило? Презрение?- это инструменты для настоящих профессионалов (ака прикладные программисты), хехe
. Основная проблема как галка собирает представление - а там используются не наименования полей, а их номера. Тем более опасно, если есть обращение к таблице в dll (класс таблицы жестко вшивается в код). Также не стоит менять размер и тем более тип стандартных полей.В данном конкретном примере не важно с пересчетом контрольной суммы это делаешь, или без. Но добавлял без пересчета контрольной суммы, без alter dictionary и без FullSQL. Просто в саппорте добавил поле по f4 на таблице.galover писал(а):а как добавлял свое поле? с пересчетом контрольной суммы или без (alter dictionary & FullSQL использовались)?