Где лучше хранить данные сумм MS SQL Server 2005

← →
Kostafey © (2007-11-29 14:43) [0]

Все просто: сушесвуют поля в базе данных (например А и Б).
Юзверь хочет видеть их сумму.
Вопрос: где лучше всего хранить эти суммы?
Варианты ответов:
1. Сделать поле А+Б и добавлять в него значения
с помошью триггера update
2. Сделать поле А+Б и добавлять в него значения
с помошью SQL-запроса из приложения
3. Сделать вычисляемое поле средствами SQL Server
4. В базе данных вообще ничего не хранить,
а вычислять средствами SQL-запросов приложения
непосредственно перед отображением пользователю.
5. ...или как-то еще...

← →
Anatoly Podgoretsky © (2007-11-29 14:49) [1]

> Kostafey (29.11.2007 14:43:00) [0]

Ничего не надо хранить.
А чем 3 отличается от 4?

← →
Kerk © (2007-11-29 14:53) [2]

> Anatoly Podgoretsky © (29.11.07 14:49) [1]

Иногда расчеты занимают много времени. Такое лучше хранить.

← →
Kostafey © (2007-11-29 14:56) [3]

> Ничего не надо хранить.

Предыдущий разработчик так не считал... :)

> А чем 3 отличается от 4?

Тем, что в 3 поле вычисляется автоматически средствами
SQL Server (к полю привязывается фомула), а в 4 средствами
приложения, или отдельным запросом приложения или частью
друго запроса, словом явно указывается в коде
(напрмер SQL-запросе) приложения.

← →
Kostafey © (2007-11-29 14:58) [4]

> [2] Kerk © (29.11.07 14:53)
> > Anatoly Podgoretsky © (29.11.07 14:49) [1]
> Иногда расчеты занимают много времени. Такое лучше хранить.

Это вряд ли такой случай, сложных расчетов нет.

← →
Johnmen © (2007-11-29 15:03) [5]

Ничего не надо хранить.

← →
boriskb © (2007-11-29 15:05) [6]

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

← →
Stas © (2007-11-29 15:08) [7]

Kostafey © (29.11.07 14:43)
Лучше сделать сохраняемое расчетное поле, как раз это поддерживает MSSQL 2005.

← →
Johnmen © (2007-11-29 15:08) [8]

> boriskb © (29.11.07 15:05) [6]
> Ну неужели не ясно, что ответ очень зависит от задачи..

А что, в [0] что-то неясно?

← →
Johnmen © (2007-11-29 15:09) [9]

> Stas © (29.11.07 15:08) [7]
> Лучше сделать сохраняемое
> расчетное поле, как раз это поддерживает MSSQL 2005.

Чем лучше? По сравнению с чем?
А в 2003 и 2000 не было?

← →
boriskb © (2007-11-29 15:12) [10]

> А что, в [0] что-то неясно?

Мне лично (по глупости моей?) ничего не ясно.
Первое - я сомневаюсь что нужна простая сумма двух полей, думаю задача упрощена для ясности.
Есть и второе и третье и еще чего.
Ты, не сомневаюсь, сам сможешь придумать такие задачи, для которых и хранение и вычисление будет оптимальным.

← →
Ломброзо © (2007-11-29 15:15) [11]

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

← →
Johnmen © (2007-11-29 15:15) [12]

> Первое - я сомневаюсь что нужна простая сумма двух полей,
> думаю задача упрощена для ясности.

Думать надо над ответом. А не вопросом....

> Есть и второе и третье и еще чего.

Можно раскрыть сущность второго, третьего и ещё чего?

> Ты, не сомневаюсь, сам сможешь придумать такие задачи, для
> которых и хранение и вычисление будет оптимальным.

Конечно. Только не "и", а "или".
Только зачем придумывать задачи? Тем более самому себе? :)

← →
boriskb © (2007-11-29 15:19) [13]

> Только зачем придумывать задачи? Тем более самому себе?
> :)

:) Ну если так ставить вопрос
Если учить задавать вопросы, а не домысливать, то конечно - спорить не о чем :)

← →
Stas © (2007-11-29 15:25) [14]

Johnmen © (29.11.07 15:09) [9]
>Лучше хранить чем считать постоянно.
2003 MSSQL не встречал, в 2000 этого небыло, расчетные поля считались каждый раз при выборке.

← →
KSergey © (2007-11-29 15:28) [15]

Как верно написано - все сильно зависит от задачи.
1) Если это всегда действительно и точно именно сумма этих двух полей - то хранить ее неразумно. Более того, считаю неразумным вообще использовать сервер для вычисления этой суммы. Уверен, клиент (который, очевидно, есть) с этим справится ничуть не хуже, а суммарная мощность всех клиентов, очевидно, много больше мощности сервера. Да и траффик лишний по сетке - ни к чему.

2) Однако, если
а) Это не всегда точно буквально сумма (например - нюансы округления до копеек)
б) пункт а) усугубляется еще и тем, сто эта "сумма" фигурирует в документах
- очевидно, что хранить ее необходимо. Причем именно хранить, а не вычислять каждый раз в запросе или на клиенте.

← →
Kostafey © (2007-11-29 15:29) [16]

> [5] Johnmen © (29.11.07 15:03)
> Ничего не надо хранить.

Да, пожалуй, впердь так и буду делать.

> [7] Stas © (29.11.07 15:08)
> Kostafey © (29.11.07 14:43)
> Лучше сделать сохраняемое расчетное поле, как раз это поддерживает
> MSSQL 2005.

Вариант 3. Угу.

> [11] Ломброзо © (29.11.07 15:15)
> В одной таблице хранить оперативные данные, а для снапшотов
> и вычисляемых значений завести аналитическую.

Боже упаси, в БД и так хаосу предостаточно.

> [10] boriskb © (29.11.07 15:12)
> > А что, в [0] что-то неясно?
>
> Мне лично (по глупости моей?) ничего не ясно.
> Первое - я сомневаюсь что нужна простая сумма двух полей,
> думаю задача упрощена для ясности.

Если быть точным, то суммируюся значения ряда полей заданного
диапазона записей.

← →
KSergey © (2007-11-29 15:31) [17]

Добавлю пункт в) к 2:

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

← →
Kostafey © (2007-11-29 15:34) [18]

> [15] KSergey © (29.11.07 15:28)
> Уверен, клиент (который, очевидно, есть) с этим справится
> ничуть не хуже, а суммарная мощность всех клиентов, очевидно,
> много больше мощности сервера. Да и траффик лишний по сетке
> - ни к чему.

Ну клиент-то тонкий.
Хотя даже если так, JavaScript, мог бы справиться с задачей.
Хм...

> а) Это не всегда точно буквально сумма (например - нюансы
> округления до копеек)

Не требуется.

> б) пункт а) усугубляется еще и тем, сто эта "сумма" фигурирует
> в документах

Это есть конечно.

← →
Anatoly Podgoretsky © (2007-11-29 15:35) [19]

> Kerk (29.11.2007 14:53:02) [2]

Что А+B занимает много времени, да в жизнь не поверю.

← →
Anatoly Podgoretsky © (2007-11-29 15:37) [20]

> а в 4 средствами
> приложения, или отдельным запросом приложения или частью
> друго запроса, словом явно указывается в коде
> (напрмер SQL-запросе) приложения.

Лиса ты меня не путай

> а вычислять средствами SQL-запросов

Ну четыре на пять не делится, вот я себе и беру неделимую половину.

← →
Kostafey © (2007-11-29 15:38) [21]

> [17] KSergey © (29.11.07 15:31)
> Добавлю пункт в) к 2:
>
> в) Если расчеты на основании каких-либо данных ведутся именно
> для этой суммы, а слагаемые получаются уже как результат
> деления этой суммы на 2 каких-либо части - опять же есть
> смысл ее хранить. Для разбора полетов.

Вопрос актуален. Обсуждался.

Но для разбора полетов там отдельный механизм :)

← →
Anatoly Podgoretsky © (2007-11-29 15:38) [22]

> boriskb (29.11.2007 15:12:10) [10]

То есть ты считаешь, что для ясности надо запутать?

← →
KSergey © (2007-11-29 15:38) [23]

> Johnmen © (29.11.07 15:15) [12]
> Думать надо над ответом. А не вопросом....

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

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

← →
boriskb © (2007-11-29 15:41) [24]

> То есть ты считаешь, что для ясности надо запутать?

:)
Скажу так:
Иногда надо, но не запутать , а усложнить

← →
Stas © (2007-11-29 15:41) [25]

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

← →
Kostafey © (2007-11-29 15:42) [26]

> [20] Anatoly Podgoretsky © (29.11.07 15:37)

ОК! Следует писать так:

4. В базе данных вообще ничего не хранить,
а вычислять средствами:
4.1. Приложения
4.2. SQL-запроса к БД, но запрос этот храниться
и вызывается непосредственно из приложения.

ку? :)

← →
KSergey © (2007-11-29 15:44) [27]

> Kostafey © (29.11.07 15:34) [18]
> Ну клиент-то тонкий.

На сколько тонкий? Все едино - как я понимаю - есть некая софтина (она тут и будет клиентом для SQL-сервера), которая лезет непосредственно на SQL-сервер и формирует ответы "тонкому клиенту". Или "тонкий клиент" непосредственно лезет на SQL-сервер??!! А что это тогда за клиент, что при этом на нем есть JavaScript??

> Kostafey © (29.11.07 15:34) [18]
> Хотя даже если так, JavaScript, мог бы справиться с задачей.
> Хм...

Ну я выше написал уже свои "непонятки" относительно того что это за "тонкий клиент" такой.

Но в любом случае еще такой есть момент: если когда-нибудь это значение таки перестанет быть тупой суммой этих двух полей - придется патчить всех клиентов (которые клиенты для SQL-сервера и собственно сумму считают). В этом плане централизованное суммирование - предпочтительнее.

← →
Kostafey © (2007-11-29 15:45) [28]

> [23] KSergey © (29.11.07 15:38)

> Вопрошающий не всегда видит задачу целиком либо, быть может,
> не сталкивался с каким-либо нюансами, пототму ему она видится
> такой вот упрощенной.
> Есть смысл указать ему на возможные нюансы, которые - быть
> может - он обнаружит в своей ситуации и сможет их учесть.

+1

> Stas © (29.11.07 15:41) [25]
> + в пользу хранения, это поле можно проиндексировать и выборка
> по нему будет проходить намного быстрее.

Имеет смысл только тогда, когда по этому полю хоть немного часто сттоят выборки. Мне на ум не приходит сколь-нибудь актуальных задач по частой выборке на основании поля "сумма".

> [27] KSergey © (29.11.07 15:44)

Кхе-кхе...
Я верно неправильно выразился.
Есть приложение работающее на сервере,
обращающееся к БД и формирующее HTML-ответы
клиентам.

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

ну, сумма незнаю, а произведение вполне достаточно. Я думаю автор образно написал A+B

> [29] KSergey © (29.11.07 15:45)
> > Stas © (29.11.07 15:41) [25]
> > + в пользу хранения, это поле можно проиндексировать и
> выборка
> > по нему будет проходить намного быстрее.
>
> Имеет смысл только тогда, когда по этому полю хоть немного
> часто сттоят выборки. Мне на ум не приходит сколь-нибудь
> актуальных задач по частой выборке на основании поля "сумма".

На самом деле такие запросы возможны (например по количеству людей или техники),
но их конечно будет не столь много.

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

CREATE TABLE Atest (ID INT Identity(1, 1) PRIMARY KEY, A INT, B INT, C AS A+B) SET ARITHABORT ON CREATE INDEX C ON Atest (C)

(MSSQL 2000)

> Kostafey © (29.11.07 15:49) [30]
> Есть приложение работающее на сервере,
> обращающееся к БД и формирующее HTML-ответы
> клиентам.

Ну тогда вот он и клиент! :)
Хотя в таком варианте я уж не знаю кто будет быстрее справляться с этой задачей. Можно провести натурные эксперименты.
Проблема обновления многих клиентов, очевидно, так же отпадает. Выносить суммирование на браузер - точно смыслу не вижу.

> Kostafey © (29.11.07 15:51) [32]
> На самом деле такие запросы возможны (например по количеству
> людей или техники),

Ага, каждые 3 секунды выполнять запрос "а в каких комнатах у нас более 50 рабочих мест?" :)

Впрочем
> но их конечно будет не столь много.
принимается :)
А вот индексы колбасить на сервере - это тоже нагрузка. И много большая вычисления относительно суммы. Так что как обычно компромисс.

KSergey © (29.11.07 16:02) [35]
Все зависит от задачи, допустим справочник организаций, для работы нужно в разные поля заносить форму собственности, наименование и т.д., А искать нужно по полному намименованию т.е. форма собственности + наименование. Или какой-нибудь справочник материалов.

> Kostafey (29.11.2007 15:42:26) [26]

> 4.2. SQL-запроса к БД, но запрос этот храниться и вызывается непосредственно из приложения.

А все равно откуда, запрос выполняется сервером.

ИМХО, хранить (из соображений производительности) следует только то, на вычисление чего расходуется достаточно много ресурсов СУБД, например агрегатные результаты, основанные на других таблицах. Хранить просто сумму 2 полей одной таблицы бессмысленно, ибо даже на поддержание актуальности этой суммы (те же тригеры) нужно затратить ресурсов едва ли не больше, чем на сам расчет.

> Sergey13 (29.11.2007 16:25:39) [39]

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

Где лучше хранить данные сумм MS SQL Server 2005 Найти похожие ветки