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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спс, за развёрнутый ответ.
Статусы отправки хранятся в таблице логов, но всё равно учёл ваши замечания.
По поводу guid, да согласен индекс будет иметь некоторую размытость, но никто не отменяет NEWSEQUENTIALID() для PK.

ViPRosProga,

2
Сахават, это не ответ. Не хватает аргументов

sphinx_mv, у ТС Enterprise

ViPRos,
Меня интересует именно физическая модель

Arm79, все твои а б в без аргументов не могут восприниматься как подтверждение выбора правильного решения. Чистый субъективизм. А хочется фактов, а не домыслов