ProgaТак вот вопрос. Как лучше сделать?
Во-первых, этот вопрос имхо вообще не очень важен. Зависит, конечно, от вашей специфики, но если это вспомогательная функция - что скорее всего - и миллионы записей вообще, а не в час, то в общем любое решение будет приемлемым, да и переделать, если захочется, будет нетрудно.

Первое соображение, которое я принял бы в расчёт - перенос. Если запись достаточно большая и траффик достаточно большой, то на каждую операцию делать паразитные delete N байт и insert N байт - становится довольно большой нагрузкой на базу. Это касается как решения "сделать таблицу", так и более вменяемых - например, партиционирования по битовому флагу. По этому соображению Ваш подход, безусловно, выигрывает.

Второе соображение - выборка неотправленных. Этот запрос должен выбирать примерно 1 / (кол-во дней * кол-во циклов отправки в день), то есть малое относительно размера таблицы количество записей. Здесь я задал бы два вопроса: во-первых, как партиционированы данные по времени и во-вторых, как они физически размещаются на диске.

Если записи ложатся на диск более-менее в естественном порядке, то неотправленные записи будут склонны кластеризироваться (сбиваться в кучу в конце таблицы). Это означает, что индекс по ним будет эффективным средством доступа (даже если число логических чтений окажется велико, физических будет довольно мало). Вы, я так понял, говорите про MSSQL. Сколь мне помнится, в нём поддерживаются частичные индексы, а значит, можно сделать индекс только по неотправленным записям и наслаждаться.

Если записи ложатся на диск вразнобой (ну скажем, если вы делаете clustered key по guid pk), то индекс становится менее эффективным. Впрочем, скорее всего, он всё равно останется лучшим решением, нежели full table scan.

Решение начальника имеет некоторое преимущество в этом моменте, поскольку позволит читать неотправленные без индекса, с помощью многоблочных чтений. Но выигрыш будет сравнительно скромен, постоянные записи из таблицы в таблицу его съедят и не заметят. Кроме того, индексные решения позволят выбирать записи по одной, без "пройди всю выборку от начала до конца"; это удобно если, например, вы заходите сделать несколько независимых экземпляров отправщика, работающих по общей очереди.

Наконец, совершенно очевидно, что статусов "послан" и "не послан" недостаточно для хорошей реализации этой функциональности. Примерный набор необходимых статусов такой:

успешно отправлен

ждёт отправки

находится в процессе отправки (может быть решено блокировкой, но для MS это вряд ли хороший вариант)

невозможно отправить, перманентная ошибка доставки

не удалось отправить, повторить попытку после заданного промежутка времени

Если же кроме отправки надо контролировать ещё и доставку, набор статусов сообразно увеличивается.

Итого - я советовал бы доработать постановку и затем решение без переноса данных, с флагом или типа того.

vadiminfoВообще-то тут плохая селективность для обычных индексов (B - деревьев): конка принимает всего два значения. Т.е. тут нужны Битмап-индексы.
Вадиииим :(

Тут перекошенное (skewed) распределение. Для sent = false селективность будет очень даже неплохой, во всяком случае на это стоит надеяться :)

ProgaТак вот вопрос. Как лучше сделать?
Да, ну и забыл упомянуть - рано или поздно на эту таблицу захочется повесить внешний ключ, и решения "перекладывать из таблички в табличку", как у них водится, сядут в лужу.

iscrafmK.I.S.S.

Валер, то, что ты пустое трепло, способное только прийти в топик и нагадить, давно известно всему форуму. Шёл бы ты в привычную тебе среду обитания. Соревноваться с тобой в хамстве я не собираюсь, а в тупости - так и не смогу, пожалуй.

iscrafmвыше все сказано 18359602
У тебя мания величия.