Предистория.
Пилю очередник отправки писем и смс.
Структура таблиц содержит весь набор полей необходимый для отправки, т.е. полностью независимый сервис.
Количество строк в таблице - миллионы.
Размерность некоторых полей nvarchar(4000).

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

Либо.
Сделать таблицу и туда складывать всё то, что должно быть отправлено, а уже при успешной отправки перекидывать отработанные строки в другую таблицу, отправленных.
Тогда выборка необработанных будет не по миллионной таблице, а по маленькой.
Это выбор моего начальника.

Аргументы у нас с ним разные.
И мы решили поспорить, что лучше.
И решили свой спор вынести на SQL.ru

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".
Ему этого мало. Я развернул свои аргументы в более развёрнутой форме, но здесь не хочу про это писать.
Нужны чёткие аргументы в пользу конкретного подхода именно от сообщества SQL.RU.

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, все твои а б в без аргументов не могут восприниматься как подтверждение выбора правильного решения. Чистый субъективизм. А хочется фактов, а не домыслов

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

забыл упомянуть
сервер.
Microsoft SQL Server 2008 (SP3) - 10.0.5828.0 (X64)
Nov 1 2012 22:54:10
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)