Это внутри базы, а за ее пределами?
Сейчас как раз разрабатываю систему синхронизации данных с партнерами. Недавно один объект стал лишним, его удалили, и партнеры предложили создать новый с тем же id - чтобы дырку заполнить.
Чуть не убил на месте! Битый час объяснял почему нельзя так делать!
Представьте, на первый объект накопилась информация, а дальше инфа начинает поступать для другого, но вы об этом еще не знаете. Что в итоге? Полный бред вместо информации.
Все так. Внутри базы мы можем контролировать, но после того как система разрастется и ее надо будет интегрировать с другими системами, начнутся проблемы.
Представьте, что в других системах есть ссылки на ваши объекты (неважно какие http, по id или еще как-то). Затем объект был удален и вместо него добавлен новый с тем же id. Внешняя система начинает работать с этим объектом - вот отличный источник «веселых» ошибок.
Как вариант, но, думаю, тут придется лочить таблицу или использовать транзакции, чтобы избежать все той же проблемы с двойной вставкой.
Насчет поведения автоинкрмента в innodb не знал (последнее время чаще работаю с другой БД). Это всегда так? Или можно как-то этого избежать?
Я вижу 2 косяка:
1) при большом кол-ве запросов возникнут глюки вставки, когда второй запрос придет между взятием max и записью max+1 в базу
2) при удалении последней записи нарушается ссылочная целостность.
Честно говоря, я ни разу не сталкивался с ситуацией, когда нельзя было использовать автоинкрементое поле. И всегда это было самое надежное решение. Поделитесь, пожалуйста, информацией когда оно не подходит.
Мне кажется, что программист (или архитектор приложения) должен сам разрабатывать структуру БД и затем передавать ее админам на внедрение и сопровождение.
В том-то и проблема, что это работает пока тестируешь на локальной машине и при маленьком потоке пользователей. А потом время от времени будет ломаться, чем больше нагрузка тем чаще.
Все из-за того, что среда многопользовательская и может придти два запроса с маленькой разницей по времени и будет конфликт ID.
Сейчас как раз разрабатываю систему синхронизации данных с партнерами. Недавно один объект стал лишним, его удалили, и партнеры предложили создать новый с тем же id - чтобы дырку заполнить.
Чуть не убил на месте! Битый час объяснял почему нельзя так делать!
Представьте, на первый объект накопилась информация, а дальше инфа начинает поступать для другого, но вы об этом еще не знаете. Что в итоге? Полный бред вместо информации.
Представьте, что в других системах есть ссылки на ваши объекты (неважно какие http, по id или еще как-то). Затем объект был удален и вместо него добавлен новый с тем же id. Внешняя система начинает работать с этим объектом - вот отличный источник «веселых» ошибок.
Насчет поведения автоинкрмента в innodb не знал (последнее время чаще работаю с другой БД). Это всегда так? Или можно как-то этого избежать?
1) при большом кол-ве запросов возникнут глюки вставки, когда второй запрос придет между взятием max и записью max+1 в базу
2) при удалении последней записи нарушается ссылочная целостность.
Честно говоря, я ни разу не сталкивался с ситуацией, когда нельзя было использовать автоинкрементое поле. И всегда это было самое надежное решение. Поделитесь, пожалуйста, информацией когда оно не подходит.
Но с переполнением проще бороться - можно установить integer или bigint - тогда переполнения придется долго ждать :)
Все из-за того, что среда многопользовательская и может придти два запроса с маленькой разницей по времени и будет конфликт ID.