Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

Stas (2007-11-29 15:41:00) [21]
+ в пользу хранения, это поле можно проиндексировать и выборка по нему будет проходить намного быстрее.

boriskb (2007-11-29 15:41:00) [22]
> То есть ты считаешь, что для ясности надо запутать?

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

KSergey (2007-11-29 15:38:00) [23]
> Johnmen © (29.11.07 15:15) [12]
> Думать надо над ответом. А не вопросом....

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

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

Anatoly Podgoretsky (2007-11-29 15:38:00) [24]
> boriskb (29.11.2007 15:12:10) [10]

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

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

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

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

Anatoly Podgoretsky (2007-11-29 15:37:00) [26]

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

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

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

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

Anatoly Podgoretsky (2007-11-29 15:35:00) [27]
> Kerk (29.11.2007 14:53:02) [2]

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

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

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

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

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

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

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

KSergey (2007-11-29 15:31:00) [29]
Добавлю пункт в) к 2:

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

Kostafey (2007-11-29 15:29:00) [30]
> [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:28:00) [31]
Как верно написано - все сильно зависит от задачи.
1) Если это всегдадействительно и точно именно сумма этих двух полей- то хранить ее неразумно. Более того, считаю неразумным вообще использовать сервер для вычисления этой суммы. Уверен, клиент (который, очевидно, есть) с этим справится ничуть не хуже, а суммарная мощность всех клиентов, очевидно, много больше мощности сервера. Да и траффик лишний по сетке - ни к чему.

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

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

boriskb (2007-11-29 15:19:00) [33]
> Только зачем придумывать задачи? Тем более самому себе?
> :)

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

Johnmen (2007-11-29 15:15:00) [34]

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

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

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

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

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

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

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

boriskb (2007-11-29 15:12:00) [36]
> А что, в [0] что-то неясно?

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

Johnmen (2007-11-29 15:09:00) [37]

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

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

Johnmen (2007-11-29 15:08:00) [38]

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

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

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

boriskb (2007-11-29 15:05:00) [40]
Ну неужели не ясно, что ответ очень зависит от задачи..
Все ответы возможны.
Не слушай никого - только тот кто знает что за велечины суммируются, как используются суммы и т.п. может аргументированно выбрать вариант.

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »