Общая производительность запросов SQL Server

Question

Это может быть глупо, но базы данных не мое дело. Представьте себе следующий сценарий. Пользователь может создать сообщение, а другие пользователи могут ответить на его сообщение, создав тем самым цепочку. Все идет в одной таблице, называемой сообщениями. Все сообщения, которые формируют поток, связаны друг с другом через сгенерированный ключ с именем ThreadID. Это означает, что когда пользователь # 1 создает новое сообщение, генерируется ThreadID, и каждый последующий ответ имеет ThreadID, указывающий на исходное сообщение (созданное пользователем # 1). То, что я пытаюсь сделать, это ограничить количество ответов, скажем, 20 на поток. Мне интересно, какой из подходов ниже:

1

Я добавляю новый столбец целых чисел (например, счетчик) к сообщениям. После того, как пользователь отвечает на исходное сообщение, я обновляю поле Счетчик исходного сообщения. Если он достигает 20, я блокирую нить.

2

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

Для получения дополнительной информации: я использую базу данных SQL Server и модель сущностей Linq-to-SQL. Буду рад, если вы выскажете свое мнение о двух подходах или поделитесь другим, более быстрым подходом.

С наилучшими пожеланиями,

Кирил

Answer 1

Был там и сделал варианты обоих решений.

Лично мне не нравится решение 1, потому что встречный столбец не имеет никакого значения для всех ответных сообщений.

Iобычно получается

3

Создать две таблицы , одну для Threads (начало потоков) и одну для Posts (ответы потоков).

Часто вы обнаружите, что для Thread имеется больше полей, чем для post .Например, вы можете добавить столбец IsLocked в таблицу Threads.Тогда вам не нужно будет запоминать магическое число (20), чтобы узнать, заблокирована ли Thread или нет.

У меня также часто есть Title для темы, но не для сообщений.И иногда другой столбец, чтобы узнать, является ли поток IsSticky или нет.И так далее ...

Answer 2

На мой взгляд, этот счетчик ответов не является ни частью сообщения, ни темой. Это системный параметр, который вписывается в другую таблицу данных. Давайте назовем это SysParams, ради этого примера.

CREATE TABLE SysParams (
    SpId int IDENTITY(1, 1) primary key
    , SpTableName nvarchar(20) NOT NULL -- To what table this parameter applies?
    , SpName nvarchar(10) NOT NULL  -- Parameter name
    , SpValue nvarchar(20) NOT NULL -- Value of the parameter
)

insert into SysParams (SpTableName, SpName, SpValue) values (N'Posts', N'MaxAnswersPerThread', N'20')
GO

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

Почему nvarchar (20) для поля SpValue ?

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

Что касается получения этих значений, вы должны кодировать функцию GetParameterValue () , которая будет просто возвращать значение поля SpValue в зависимости от SpTableName и SpName , указанное при вызове функции. Таким образом, вы можете использовать другие параметры для одной и той же таблицы для разных целей.

Answer 3

Вариант 2 будет в порядке, если у вас есть индекс на ThreadID. Вариант 1 также подойдет (при условии, что у вас есть индекс на ThreadID), но я думаю, что код будет более сложным.