А количество записей - принипиально?
Если исходить из предположения, что данное ограничение связано с экономией дискового пространства, то может задачу можно несколько видоизменить, например условие "количество записей" заменить на "записей за последние 30 дней" скажем?
Если так, то все будет гораздо проще. Иначе - "тяжелые" SQL запросы, о которых говорилось выше, или какие-нибудь трюки.

PVPЕсли позволить накопление записей, то самая тяжелая часть SQL-запроса при удалении будет
"... from table_b inner join table_a on ...". А там же есть еще и "...Where ...". И сколько времени будет проходить удаление, можно только догадываться, а следовательно гадать "Пройдет до началы смены или нет?"

Не понял проблемы. В случае "записей за последние 30 дней":

-- for Sybase ASE 12.x
DELETE MyTable WHERE MyDate < convert(char(8),dateadd(dd,-30,getdate()),112)

Где там join?

папа Карлоза посл. 30 дней удаляем сейчас и как бы работает без проблем..... проблема в том, что по некоторым ИД записи в логе появляются скажем раз в год или два года, без системно, но далеко не каждый день, именно поэтому поступило требование хранить последние Н(30-40) обзоров.

апдейт не подходит совсем... дата (в виде инта) в индексе и никуда ты от нее не денешься... было бы интересно посмотреть на солюшен с пометкой записей которые надо удалить....

ну и между делом..... тут код привели....


так никто не удаляет.... ибо индексы не работают.....


тьщательнее товарищи.... не допускаем тейблсканов..... ;)
А я ведь недаром указал версию СУБД, когда такой "странный" запрос с конвертацией даты привел.
На Syabse ASE в такой форме запрос работает быстрее, нежели с getdate(), т.к. оптимизатор сначала вычисляет выражение, а потом использует его, как переменную, а преобразование же char->datetime происходит автоматом.
И, как ни странно, никакого tablescan не происходит.
Вот такой загадочный Sybase :0)