|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть несколько однотипных таблиц, нужно повесить на них триггер, который будет складывать их данные в одну таблицу. В этой таблице нужно хранить названия тех, откуда взяты данные. Я так понимаю, одним триггером этого не решить и придётся создавать по триггеру на каждую таблицу? Возможны ли альтернативные решения?
Неактивен
Имхо, лучше будет делать добавление в исходные таблицы через процедуру, которая будет добавлять сразу и во вторую таблицу.
С триггером возможна ситуация, что в таблицу добавилась запись, а потом сбой и во вторую запись не добавилась.
А зачем нужна такая архитектура? Может достаточно представления на основе однотипных таблиц?
Неактивен
vasya написал:
А зачем нужна такая архитектура? Может достаточно представления на основе однотипных таблиц?
С представлениями дела не имел, опишу подробнее ситуацию.
Мы предоставляем сервис смс рассылок, один из вариантов удалённого взаимодействия (смс шлюз) - добавление данных об смс в персональную таблицу. Для этого мы на отдельном СУБД в специальной БД создаём нового пользователя и таблицу для его смс, права на эту таблицу имеет только этот пользователь. По крону запускается скрипт раз в минуту и проходит по всем таким пользовательским таблицам в поисках новых смс для отправки. Сейчас количество таких таблиц перевалило за полторы тысячи и скрипт уже не успевает проверить их все за 1 минуту. Настало время рефакторинга...
Первое, что приходит на ум - это скидывать все новодобавленные данные в одну таблицу и чтобы скрипт по крону выгребал уже записи из неё. Т.к. пользователи не могут иметь доступ к данным других пользователей, а значит и к новой общей таблице, в решении я вижу использование триггера. В общей таблице нам нужно знать от какого пользователя (из какой таблицы) поступили данные.
ЗЫ Таблицы по структуре вцелом одинаковые, но есть такие, в которых есть дополнительное поле для нужд клиента, мы такие поля не используем.
Неактивен
Вася правильно предложил. Вставлять процедурой, которая будет сразу вставлять sms и в общую таблицу. В этом случае можно в транзакции убедиться, что sms действительно вставилась в обе таблицы.
Неактивен
А как различать кто вызвал процедуру? Придётся передавать в параметре имя пользователя/таблицы? И наверное возникнет сложность с доп.полем, которое есть не во всех таблицах и может иметь разное название и даже тип, разбаловали мы клиентов)))
Неактивен
Neval написал:
А как различать кто вызвал процедуру? Придётся передавать в параметре имя пользователя/таблицы
Да.
Neval написал:
И наверное возникнет сложность с доп.полем, которое есть не во всех таблицах и может иметь разное название и даже тип, разбаловали мы клиентов)))
Эта сложность возникнет и в случае триггера. Но если вы это поле не используете, то процедура может копировать в общую таблицу только нужные данные.
Если отбросить доп поле, то вопрос прав на отдельные строки как раз и решается с помощью представления
Неактивен
В свои таблицы клиенты как пишут данные, так и читают их в дальнейшем, по сему значение в доп.поле мы им должны добавить (при использовании вставки через процедуру). Для триггера значение доп.поля не нужно, т.к. оно не нужно нам для обработки, и соответственно для него не будет поля в общей таблице. Т.е. клиент пишет в свою табличку что считает нужным, а триггер берёт оттуда только то, что нужно нам, а эти поля точно у всех одинаковые.
Права на отдельные строки штука интересная, но нам не подойдёт, если я правильно понял это выражение. Пользователи смогут писать напрямую в одну общую таблицу и совсем не использовать персональные таблицы? У нас получается не совсем принцип очереди, данные могут храниться разное количество времени, у активных клиентов не редко скапливаются миллионы записей за относительно небольшой промежуток времени. Если мы это всё запихнём в одну табличку, наверн будет армагедец))
По представлениям ещё почитаю, чтобы хотя бы понимать что к чему, солидный такой объём в статейке))
Пока-что "насобирали" два варианта решения задачи:
1. По триггеру на таблицу. Минусы: кол-во триггеров = кол-во таблиц = кол-во пользователей; есть шанс сбоя.
2. Процедура, принимающая данные для записи в таблицы. Минусы: нестандартный подход; существующим клиентам придётся отредактировать своё ПО 
3. Мож чё упустил?
А по ODBC вызов процедур срабатывает? Или по ODBC можно всё-всё, как в консоли?
Неактивен
А чем минус количество триггеров? Таблицы клиентам вы создаете единожды? Вот при создании сразу и делать триггер. Минусом будет только возможность сбоя.
Neval написал:
А по ODBC вызов процедур срабатывает?
Зависит от версии. Если очень древний драйвер, то нет.
Neval написал:
у активных клиентов не редко скапливаются миллионы записей за относительно небольшой промежуток времени.
Это через вас спамеры рассылают смс?
Неактивен
vasya написал:
А чем минус количество триггеров? Таблицы клиентам вы создаете единожды? Вот при создании сразу и делать триггер. Минусом будет только возможность сбоя.
Ну как бы получается "не аккуратненько". Да, табличка создаётся один раз, но может быть удалена или переименована. При переименовании привязанный к ней триггер перенесётся автоматом или придётся пересоздавать триггер?
vasya написал:
Зависит от версии. Если очень древний драйвер, то нет.
В активном пользовании драйвер 3.ХХ, реже 5.1.
vasya написал:
Это через вас спамеры рассылают смс?
Ассоциации у людей в большинстве случаев одинаковые)) Если смс рассылки, значит спамеры 
Нет, банки шлют отчёты по движению средств на счетах, разные интернет магазины состояние заказов, такси инфу по машинам.
Неактивен
Neval написал:
Ну как бы получается "не аккуратненько". Да, табличка создаётся один раз, но может быть удалена или переименована. При переименовании привязанный к ней триггер перенесётся автоматом или придётся пересоздавать триггер?
Практика критерий истины, вы могли бы и сами проверить:
Neval написал:
В активном пользовании драйвер 3.ХХ, реже 5.1.
Емнип, 3.Х уже достаточно.
Neval написал:
Ассоциации у людей в большинстве случаев одинаковые)) Если смс рассылки, значит спамеры
Нет, банки шлют отчёты по движению средств на счетах, разные интернет магазины состояние заказов, такси инфу по машинам.
Ассоциация не на смс, а на миллионы смс. Это две большие разницы, как говорят в Одессе.
Неактивен
Neval написал:
Ассоциации у людей в большинстве случаев одинаковые)) Если смс рассылки, значит спамеры
Мне одно время приходили смски счастья в забавном сочетании - одни предлагали взять кредит, другие купить золото. Было впечатление, что они объединили бренды
Неактивен
Ой, да народ чё только не шлёт)) Есть и остатки по складу шлют, целая простыня текста
vasya написал:
Практика критерий истины, вы могли бы и сами проверить:
Я не на столько хорошо знаю это кунг-фу, к сожалению, два часа выпало бы из жизни)) Спасибо за наглядный пример.
Кстати, в примере используется bi триггер, это натолкнуло на мысль, что если их использовать в моём случае, то в случае сбоя запись не будет добавлена ни в одну таблицу?
Неактивен
before insert означает, что действие триггера выполняется до команды INSERT, т.е. возможна ситуация - в общую запись будет добавлена, а INSERT в личную не сработает.
Неактивен
да, но если в триггере будет только запрос инсерта, то сбой может быть только при его выполнении и значит записи не будет нигде Или, теоритически, сбой может быть и на END триггера? Аварийное отключение электричества в момент выполнения не считаем)))
Даже если в общей запись будет, а в личной нет, обработчиком общей очереди можно будет добавить соответствующую запись в личную таблицу, он всё равно туда будет лазить и апдейтить состояние обработанных смс. Правда такой подход тоже сопливый получается... ну то уже буду думать решение, поле для размышлений имеется
Буду таки триггеры применять, всем спасибо за помощь.
Неактивен
Neval написал:
да, но если в триггере будет только запрос инсерта, то сбой может быть только при его выполнении и значит записи не будет нигде
В этом случае - да, но сбой может быть после триггера. Кроме электричества могут быть и другие причины почему не выполнится основной инсерт, например, ошибка диска.
Неактивен
