Страница 1 из 2

Изменение словаря, чем грозит.

Добавлено: 30 сен 2010, 11:53
Vik
Добрый день. Возникла необходимость добавить в таблицу KatMc свое поле и индекс. Наслышан о том, что такое действие категорически не рекомендуется. В частности, выдержка из документации:

Код: Выделить всё

Категорически не рекомендуется пользователям использовать alter dictionary, т.к. при этом летит КС словаря. Соответственно, становится невозможен контроль соответствия приложения и БД. Отсюда возможны (и были реально) крупные неприятности. Теоретически - вплоть до полной потери БД.
Но тут не написано ничего про добавление нового поля. Кто-нибудь изменял стандартные таблицы, имел после этого проблемы? В общем, кто что посоветует?

Re: Изменение словаря, чем грозит.

Добавлено: 30 сен 2010, 12:25
edward_K
добавление нового поля, индекса, таблицы в автомате изменит контрольную сумму. Для нормальной работы ее нужно сбрасывать в 0.
В теории добавить можно, но только в конец. Тоже касается и индексов. Иначе 100% глюки. Более безопасно добавить свою таблу.
Ну и готовтесь к решению проблем с конвертацией или запуском chkmssql например. Перед этими процессами желательно привести базу в первозданный вид(особенно перед конвертацией, chkmsql лечится и так, но не у всех получается).

Re: Изменение словаря, чем грозит.

Добавлено: 30 сен 2010, 12:39
Vik
Спасибо, тогда, наверное, буду искать другой путь.

Re: Изменение словаря, чем грозит.

Добавлено: 04 окт 2010, 14:23
Sheinina
Поле и индекс в существующей таблице действительно добавлять не стоит. А вот таблицы добавляла неоднократно и проблем не испытывала. При конвертации просто надо инфу из своих табличек прикопать, после конвертации снова их создать и закачать инфу на место. Контрольная сумма изменяется одним запросом.
Все вышесказанное делала на Первасиве :)

Re: Изменение словаря, чем грозит.

Добавлено: 04 окт 2010, 15:53
Vik
Таблицы свои я и сам неоднократно создавал, тут у меня вопросов нет никаких. Меня интересовало лишь, какие проблемы могут быть именно при добавлении поля в стандартную таблицу.

Re: Изменение словаря, чем грозит.

Добавлено: 07 окт 2010, 20:05
Vik
В общем, вот что говорят сами разработчики (товарищ cruger):
Модификация словаря

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

Пользовательская модификация словаря осуществляется простым запуском соответствующих запросов (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
Нашел тут
Так что можно добавлять поля все же)

Re: Изменение словаря, чем грозит.

Добавлено: 08 окт 2010, 08:58
ilshat
- это инструменты для настоящих профессионалов (ака прикладные программисты), хехe
Вот это "ХЕХЕ" меня более всего добило. Не пойму до сих пор что это значило? Презрение?
Порог вхождения в нормальный SQL, к примеру, намного ниже, чем в недо-SQL галактический.
А докомпилировать словарь все равно ссыкотно. Пусть уж будут внешние атрибуты, так спокойнее.

Re: Изменение словаря, чем грозит.

Добавлено: 08 окт 2010, 10:12
edward_K
если поля добавлять в конец, то в принципе все работает. Основная проблема - конвертация, нужно проверять изменилась ли таблица, и если да, то приводить сначала в первозданный вид, а после конвертации(лучше даже модифицировать стандартную докомпиляцию словаря) добавлять снова. Удалять индексы или сегменты индекса очень не безопасно.Добавить свой может быть, но тоже в конце. У меня было модифицированно штук 5 стандартныз табл когда-то - и ничего после выработки таких правил окна стали открываться даже с данными :). Основная проблема как галка собирает представление - а там используются не наименования полей, а их номера. Тем более опасно, если есть обращение к таблице в dll (класс таблицы жестко вшивается в код). Также не стоит менять размер и тем более тип стандартных полей.

Re: Изменение словаря, чем грозит.

Добавлено: 08 окт 2010, 12:05
galover
почему не стОит? А если не шаманить с контрольной суммой, то есть не изменять ее как крюгер-Терсин советует, все равно будут проблемы?

Re: Изменение словаря, чем грозит.

Добавлено: 08 окт 2010, 12:28
m0p3e
Если есть необходимость добавлять поля в таблицу и потом по ним желательно иметь индексы, то делал таблицу дубликат. Например к KatMc добавляем таблицу KatMcEx. В нее добавляем поле cKatMc = KatMc.nrec и новые поля. Описываем индексы. Никаких проблем с дальнейшей докомпиляцией. А играя с программными триггерами можно обеспечить и ссылочную целостность.

Re: Изменение словаря, чем грозит.

Добавлено: 18 окт 2010, 16:02
Vik
Насчет того, какие могут возникнуть проблемы. У тестовой базы добавил в поле KatMc свое поле. Долго работал, проблем никаких уже и забыл, что поле добавил. А добавил я поле в той базе, с которой компилировал свои ресурсы. И вот в один момент, несколько моих интерфейсов стали выдавать ошибку о несовпадении контрольной суммы интерфейса oObjMc_Obj1 (я его частенько использую). Я подумал, что проблема в том, что изменилось описание - но, как узнал от разработчиков, описание этого интерфейса не менялось с 2006 года. В итоге, убил полдня, прежде, чем вспомнил, что буффер таблицы KatMc в моей базе отличается от оригинального, потому как я добавлял поле. Таким образом, при добавлении своего поля в таблицы, буфферы которых участвуют в качестве типов в объектных интерфейсах, использовать эти объектные интерфейсы становится невозможным или затруднительным.

Re: Изменение словаря, чем грозит.

Добавлено: 18 окт 2010, 16:14
galover
а как добавлял свое поле? с пересчетом контрольной суммы или без (alter dictionary & FullSQL использовались)?

Re: Изменение словаря, чем грозит.

Добавлено: 18 окт 2010, 16:56
Vik
galover писал(а):а как добавлял свое поле? с пересчетом контрольной суммы или без (alter dictionary & FullSQL использовались)?
В данном конкретном примере не важно с пересчетом контрольной суммы это делаешь, или без. Но добавлял без пересчета контрольной суммы, без alter dictionary и без FullSQL. Просто в саппорте добавил поле по f4 на таблице.

Re: Изменение словаря, чем грозит.

Добавлено: 18 окт 2010, 17:41
galover
Так лучше не делать, нужно подготовить lot и vip-ом прогнать. Есть подозрение, что контрольная сумма как раз и поменялась.

Re: Изменение словаря, чем грозит.

Добавлено: 18 окт 2010, 18:04
Vik
Да какая разница в этом случае? Ошибка будет независимо от того, была пересчитана контрольная сумма словаря или нет. Тут все упирается в то, что изменилась структура таблицы KatMc. И, как следствие, type$KatMc в моем словаре не будет равен type$KatMc в оригинальном словаре. Соответственно, и объектные интерфейсы, использующие буферы таблицы KatMc будут различаться. Глубоко фиолетово, был ли при этом использован alter dictionary иди FullSQL при изменении таблицы KatMc. Разве не так?