|
Задавайте вопросы, мы ответим
Вы не зашли.
Не могу разобраться в триггерах, может кто-нибудь написать пример триггера "Если количество строк в таблице стало 1.000.000, создать рядом новую со след. порядковым номером, и сюда больше записи не принимать"?
Неактивен
В триггере нельзя создать новую таблицу.
Неактивен
А переместить или переименовать?
Неактивен
Нет.
Неактивен
А заблокировать?
Просто надо, чтоб было не больше скажем 1.000.000 записей.
Начала писать, через show table status могу по auto increment проверить набралось ли уже, но вот проблема, там может быть 999.998, пока проверяю, пока отсылаю, а там уже до меня навысылали, и мне придёт auto increment 1.000.015 хотя он уже должен быть в другой таблице. А нельзя ли проверку запихнуть в сам запрос записи? Так, чтоб если не прошло, можно было бы дальше плясать, создавать из ПХП уже следующию...
Неактивен
По-моему, Вы изобретаете партиционирование.
Неактивен
Здраствуйте Paulus, ну да, как и пару месяцев назад, я занята всё тем же )
Не подскажете, как грамотней сделать так, что бы в таблице был максимум ровно один миллион записей?
Неактивен
Сделайте партиционирование по id на сто разделов по миллиону значений?
Неактивен
А можно ещё раз написанное, но простым языком? 
Неактивен
Неактивен
Так ведь это партицирование файлов или?
Неактивен
Ну, на уровне ФС - вроде того.
Но на уровне работы с базой данных это не так важно. С точки зрения написания SQL-запросов все это остается одной таблицей (в чем и прелесть партиционирования; бывает важно помнить, что данные разбиты по разделам - но это уже с точки зрения оптимизации производительности).
Неактивен
Ну вот видите, а мне надо разбить базу на таблицы, каждую ограничить 1.000.000 записей, при превышение, создавать новую со след. порядковым номером.
Неактивен
Триггером вы такое точно не сделаете.
Допустимо чтобы таблица временно превышала 1 млн записей? Тогда вы можете периодически (например с помощью event) делать проверку и если записей больше, то 1 млн записей переносится в новую таблицу.
В этом случае основную таблицу (в которую идет запись) можно и не переименовывать.
Неактивен
Нет, нельзя. При достижении лимита, надо создать новую таблицу и поставить auto_inrement = номмертаблицы*1.000.000+1
Неактивен
У каждой задачи есть свой смысл. Ваша задача по описанию — партиционирование.
Если Вы хотите решить не задачу в целом, а просто выполнить ТЗ, то ТЗ выполнить
нельзя, т.к. в триггере создать таблицу нельзя.
Обеспечить ровно миллион строк в таблице тоже нельзя (потому что, например, что
Вы будете делать после удаления 47й строки?)
Неактивен
Там не будет удаления вообще. Только добавление.
Неактивен
И не будет выборок вообще. Только добавление.
Эта форма организации данных называется «журнал», очень рекомендую.
Делаете файлик на диске, в него складываете миллион строк, потом дела-
ете следующий файлик 
Что касается базы данных — ну, давайте чуть более сложный пример.
есть таблица с 999 999 записями, и одновременно приходят два запроса на
вставку. Какой попадет куда? И почему? Как Вы собираетесь поступать
с такими транзакциями?
Неактивен
Первый на обработку должен попасть внутрь, а второй получить отказ
Неактивен
Отказ?
Напишите триггер, который запрещает вставку в таблицу, если в ней более
миллиона строк. Будут отказы. Увидели отказ — создали новую табличку
Неактивен
Без понятия как это делается 
Неактивен
Если MySQL 5.5, то можно просто выставить сигнал: http://dev.mysql.com/doc/refman/5.5/en/signal.html
В более ранних версиях прийдется написать какой-то костылик. Например,
SELECT THIS_IS_AN_ERROR FROM INEXISTENT_TABLE;
Неактивен
Это в каких же репозаториях уже есть версия 5.5.
Неактивен
Паулус, можно про "костылёк" поподробней?
Неактивен
Скорее всего Паулус вот про вот этот костыль упоминал - внесение в триггер запроса, который обязательно свалится.
Или SELECT THIS_IS_AN_ERROR FROM INEXISTENT_TABLE; - выбрать несуществующее поле из несуществующей таблицы - стопроцентный вариант.
Неактивен
