Есть БД, как ограничить её до допустим 10000, и при привышении лимита старые значения должны удалятся. Т.е. очередь, а при превышении лимита записи просто выкидыватся. Быстродействие критично. 


Это сообщение отредактировал(а) Madonna - 4.8.2011, 12:47

Триггер, вероятно...

Да, наверное, триггер. Спасибо.

ЕННсли критично быстродействие, рекомендую сразу забить в таблицу 10к пустых записей, и в instead of insert триггере апдейтить самую старую запись.

чуть подкоректирую предложение Akina. 
тригер не нужен. написать процедуру добовления, которая будет менять одну из самых старых.

kobra, да, это будет чуть-чуть быстрее, но зато потеряется единообразие. Да и вытаскивание логики на клиента...

имеется в виду процедура на сервере, так что с единообразием все будет в порядке 

Для случая с триггером можно как нить обеспечить согласованность конкурентной записи, если клиент установит уровень изоляции транзакций в грязные чтения? В смысле можно как нить избежать ситуации, когда два одновременно запущенных в разных сессиях инсерта ,  выберут для апдейта одну и ту же запись, не зависимо от уровня изоляции, установленном во вне.

Добавлено через 10 минут и 28 секунд
Наверно - да, если не подменять инсерт апдейтом, а делать делит, следом инсерт.....

Однако в этом случае будет случаться херня, если один из двух конкурирующих инсертов откатится, то второй, может заместить собой не ту запись, которую должен бы был.  

Всетке склоняюсь к процедуре, сераалайзабл, и примерением с потерей приозводительности

Это сообщение отредактировал(а) Zloxa - 5.8.2011, 14:50

На сколько я понимаю - да, используя <table_hint>  

Это сообщение отредактировал(а) Zloxa - 5.8.2011, 15:17