Название: Вопрос по IBExpert Отправлено: Astrologer от Октябрь 07, 2010, 09:31 Скачал, установил. Создаю две таблицы.
master: Код: /******************************************************************************/ slave: Код: /******************************************************************************/ После вставки в master, данные в slave не обновляются. Транзакции завершаю, вижу что запись прошла в master таблице. В slave - все так же пусто. Что я не так делаю? Заранее спасибо. Название: Re: Вопрос по IBExpert Отправлено: vipet от Октябрь 07, 2010, 10:10 А шо бы ви хотели шоб было?
Название: Re: Вопрос по IBExpert Отправлено: Astrologer от Октябрь 07, 2010, 10:13 Чтобы данные при вставке в master вставлялись бы и в slave.
Название: Re: Вопрос по IBExpert Отправлено: Astrologer от Октябрь 07, 2010, 10:46 Видимо надо написать триггер after insert, чтобы вставлялось. Еще бы знать как ;D
Название: Re: Вопрос по IBExpert Отправлено: Astrologer от Октябрь 07, 2010, 11:12 Код: CREATE OR ALTER trigger master_ai0 for master Название: Re: Вопрос по IBExpert Отправлено: vipet от Октябрь 07, 2010, 12:18 На всякий случай семантика терминов Master-Slave:
Одной записи в Master-таблице может соответствовать много записей в Slave-таблице. Пример: Код: Department Название: Re: Вопрос по IBExpert Отправлено: vlad-mal от Октябрь 16, 2010, 22:41 2 Astrologer: нет никаких master и slave, это все выдумки.
Master - detail. Detail связывается с master c помощью FK - ограничения. Если хочешь, чтобы при изменении ключевого поля в master менялись значения в detail's, при создании fk - ограничения укажи опцию 'cascade' на операцию "изменение". Однако, обычно это безобразие и волюнтаризм: первичные ключи меняться не должны. Название: Re: Вопрос по IBExpert Отправлено: vipet от Октябрь 17, 2010, 13:14 2 Astrologer: нет никаких master и slave, это все выдумки. Master - detail. Detail связывается с master c помощью FK - ограничения. Если хочешь, чтобы при изменении ключевого поля в master менялись значения в detail's, при создании fk - ограничения укажи опцию 'cascade' на операцию "изменение". Однако, обычно это безобразие и волюнтаризм: первичные ключи меняться не должны. Если в качестве первичного ключа задавать, напр., текстовое название отдела, а в detail т-це сотрудников делать FK надо это поле, то каскадный апдейт вполне обоснован. Более того, различные нормализации схемы БД так и говорят делать. Только понятно, что в реальной жизнь, если БД достаточно большая, в качестве PK лучше делать int ID. Название: Re: Вопрос по IBExpert Отправлено: sarbash от Октябрь 21, 2010, 22:24 В качестве первичного ключа всегда лучше использовать суррогатный, если натуральный не целочисленный. Из соображений быстродействия и производительности.
Название: Re: Вопрос по IBExpert Отправлено: Zmeishe от Октябрь 22, 2010, 09:45 Попала мне одна базища по ЖКХ.
В качестве ключа был номер лицевого счёта, благо в integer укладывался. В куче таблиц куча триггеров. Триггеры срабатывали если изменялось значение лицевого счёта в ячейке. Например, нужно было ошибочно зачисленные деньги перебросить с одного лицевого на другой. А теперь представьте в какой даун должен был уйти сервак со всеми этими каскадными обновлениями, когда понадобилось сменить нумерацию всех лицевых счетов с 7-ми цифр до 9-ти. Поэтому только суррогатный ключ. Натуральный хорош в хранилище данных, где нет никакой математики. Название: Re: Вопрос по IBExpert Отправлено: vlad-mal от Октябрь 27, 2010, 03:44 1. Забавная статья: "Ключи или отмычки" : http://www.alexus.ru/russian/articles/dbms/keys/index.htm :o
2. Естественно, статья Тенцера "Естественные ключи против искусственных ключей" : http://ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html |