А как правильно вносить изменения в БД?
-
Kotъ-Begemotъ
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
А как правильно вносить изменения в БД?
Вот допустим надо мне добавить в таблицу новое поле. Можно это делать "наживую" то есть при работающих с этой таблицей пользователях? Если допустим exe'шник клиентский еще "старый" и к этому полю не обращается. Могу я сделать ALTER TABLE и добавить поле и пропадейтить его какими-то значениями? Или надо обязательно сделать базе шотдаун и только тогда добавить?
Re: А как правильно вносить изменения в БД?
крайне желательно именно в монопольном режимеKotъ-Begemotъ писал(а):Вот допустим надо мне добавить в таблицу новое поле. Можно это делать "наживую" то есть при работающих с этой таблицей пользователях? Если допустим exe'шник клиентский еще "старый" и к этому полю не обращается. Могу я сделать ALTER TABLE и добавить поле и пропадейтить его какими-то значениями? Или надо обязательно сделать базе шотдаун и только тогда добавить?
ибо на рабочей при таких манипуляциях последствия, как говорится не гарантируются (сам подумай - ты меняешь структуру БД)базе шотдаун
-
Kotъ-Begemotъ
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
Re: А как правильно вносить изменения в БД?
Понял, пасиб... Просто надеялся что по сравнению с Paradox который у меня сейчас используется можно будет делать "на ходу"... Раскатал губу, короче... *уходит искать хорошую губозакаточную машинку*...stix-s писал(а):крайне желательно именно в монопольном режиме ибо на рабочей при таких манипуляциях последствия, как говорится не гарантируются (сам подумай - ты меняешь структуру БД)
Использование поля тут не при чём.
Скорее всего, ты получишь "object in use", потому как сама таблица всё ж используется.
Изменения метаданных на ходу - вообще грабли заточенные. Тебе хочется, чтобы на одном компе работали старым способом, а на другом уже по-новому? Мне вот почему-то хочется, чтобы все в какой-то момент начали по-новому.
ЗЫ: Вот тебе, сам просил
Скорее всего, ты получишь "object in use", потому как сама таблица всё ж используется.
Изменения метаданных на ходу - вообще грабли заточенные. Тебе хочется, чтобы на одном компе работали старым способом, а на другом уже по-новому? Мне вот почему-то хочется, чтобы все в какой-то момент начали по-новому.
ЗЫ: Вот тебе, сам просил
Жестковатый ответ. По нашему опыту работы в многопользовательской системе, постороенной на FB добавление полей проблем не вызывает. Сложнее с модификацией ХП созданием вторичных ключей. Впрочем, насколько мне известно FB2 лопускает генерацию вторичных ключей на лету.WildSery писал(а):Использование поля тут не при чём.
Скорее всего, ты получишь "object in use", потому как сама таблица всё ж используется.
Изменения метаданных на ходу - вообще грабли заточенные. Тебе хочется, чтобы на одном компе работали старым способом, а на другом уже по-новому? Мне вот почему-то хочется, чтобы все в какой-то момент начали по-новому.
Возможность работы старого приложения с заново генерироаванным полем определяется тем, как сделано приложение. Есть прижения, интерфейс которого управляется данными. В таких приложениях прозрачность нового поля обеспечивается на уровне БД без перестройки кода.
-
Kotъ-Begemotъ
- Сообщения: 250
- Зарегистрирован: 25 июл 2007, 21:33
добавлю свой камень....
использую Fb 1.5.2 CS.
добавления полей, изменения процедур-триггеров
делаю почти всегда во время работы юзеров.
потом говорю всем - перезапустите программу.
за 2 года таких манипуляций сбоев не было - может везло.
зато удобно.
ЗЫ...
IBExpert при комиляции например процедуры умеет говорить "object in use".
если в Script Executive написать конструкцию ALTER PROCEDURE... изменения проходят.
использую Fb 1.5.2 CS.
добавления полей, изменения процедур-триггеров
делаю почти всегда во время работы юзеров.
потом говорю всем - перезапустите программу.
за 2 года таких манипуляций сбоев не было - может везло.
зато удобно.
ЗЫ...
IBExpert при комиляции например процедуры умеет говорить "object in use".
если в Script Executive написать конструкцию ALTER PROCEDURE... изменения проходят.
Сильно зависит от БД.SAMZ писал(а):Жестковатый ответ. По нашему опыту работы в многопользовательской системе, постороенной на FB добавление полей проблем не вызывает.
У нас вот частично из-за избыточности, частично из-за нечувствительности системы к некоторым потерям, можно некоторые данные вообще поубивать в системе, и ничего не случится. Не логи, причём.
А вот представь другую ситуацию.
Есть таблица, скажем, цен. Есть ХП, которая по определённым правилам оттуда их достаёт, пересчитывает и выдаёт запросившему (другой ХП, к примеру).
Добавляем колонку с новой, условно, "скидкой". Изменяем эту ХП, чтобы расчёт проводился с использованием этой колонки (иначе нафиг она нужна?).
Итак, видим: один клиент работает с этой таблицей со старой процедурой, второй клиент работает уже с новой. А с административной точки зрения, все работают с новой. Они там такого наработают...
Если же менять какие-нибудь важные триггеры...
Согласен, но здесь речь уже о бизнес логике, а не собственно метаданных и допустимости их модификаций на лету с точки зрения сервера.WildSery писал(а): А вот представь другую ситуацию.
Есть таблица, скажем, цен. Есть ХП, которая по определённым правилам оттуда их достаёт, пересчитывает и выдаёт запросившему (другой ХП, к примеру).
Добавляем колонку с новой, условно, "скидкой". Изменяем эту ХП, чтобы расчёт проводился с использованием этой колонки (иначе нафиг она нужна?).
Итак, видим: один клиент работает с этой таблицей со старой процедурой, второй клиент работает уже с новой. А с административной точки зрения, все работают с новой. Они там такого наработают...
Если же менять какие-нибудь важные триггеры...
Исходя из множества ответов, делаю вывод, что на вопрос автораWildSery писал(а):Дык я никоим образом о сервере речи и не вёлSAMZ писал(а):Согласен, но здесь речь уже о бизнес логике, а не собственно метаданных и допустимости их модификаций на лету с точки зрения сервера.
В нём-то как раз всё правильно работает, строже или мягче - не важно.
я ответил неверно с точки зрения целостности БДВот допустим надо мне добавить в таблицу новое поле. Можно это делать "наживую" то есть при работающих с этой таблицей пользователях? Если допустим exe'шник клиентский еще "старый" и к этому полю не обращается. Могу я сделать ALTER TABLE и добавить поле и пропадейтить его какими-то значениями? Или надо обязательно сделать базе шотдаун и только тогда добавить?
хотя сам никогда на лету не меняю ничего и не добавляю (перестраховываюсь так сказать)
хотя у меня и масштабы вовсе не промышленные
Да ничего подобного. Поля добавлять можно. Если под целостностью здесь имеется ввиду отсутствие фатальных последствий для БД в смысле ее живучести, то ничего не нарушится. Ну, а в отношении бизнес логики, то разработчик сам должен думать о последствиях действий такого рода.stix-s писал(а):я ответил неверно с точки зрения целостности БД :(
хотя сам никогда на лету не меняю ничего и не добавляю (перестраховываюсь так сказать)
хотя у меня и масштабы вовсе не промышленные :)
Хотяяяя, пришла в голову мысль - хорошо, в старом клиенте поле не пользуется, но наложили на него ограничение not null и дефолта нетSAMZ писал(а): Да ничего подобного. Поля добавлять можно.
Обломается ведь ползатель со старым клиентом
или он из-за кеша метаданных его и не увидит до переконнекта?
Не, я уж все-таки лучше монопольно менять буду