Мастера 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. ...или как-то еще...

Kostafey (2007-12-01 01:09:00) [1]
> [44] ЮЮ © (30.11.07 11:58)
> Напротив, исправить SP (UDF) на сервере, не меняя приложения
> у клиентов, по-моему проще.

Спасибо, но клиент для БД фактически 1 -
это Web-прилоение.

ЮЮ (2007-11-30 11:58:00) [2]
> [43] Kostafey © (30.11.07 11:50)

Напротив, исправить SP (UDF) на сервере, не меняя приложения у клиентов, по-моему проще.

Kostafey (2007-11-30 11:50:00) [3]
> [38] Anatoly Podgoretsky © (29.11.07 16:15)
> > Kostafey (29.11.2007 15:42:26) [26]
>
> > 4.2. SQL-запроса к БД, но запрос этот храниться и вызывается
> непосредственно из приложения.
>
> А все равно откуда, запрос выполняется сервером.

Спору нет, сервером.
Но это упрощает работу, т.к. не нужно
вносить изменения в структуру уже работающей БД,
а лишь обновить приложение.

Anatoly Podgoretsky (2007-11-29 19:32:00) [4]
> Sergey13 (29.11.2007 16:55:41) [41]

Важно предусмотреть процедуру перерасчета.

Sergey13 (2007-11-29 16:55:00) [5]
> [40] Anatoly Podgoretsky © (29.11.07 16:40)

Это да, проверять актуальность нужно в этом случае нужно. Но с другой стороны это можно делать в ночное время например.

Anatoly Podgoretsky (2007-11-29 16:40:00) [6]
> Sergey13 (29.11.2007 16:25:39) [39]

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

Sergey13 (2007-11-29 16:25:00) [7]
ИМХО, хранить (из соображений производительности) следует только то, на вычисление чего расходуется достаточно много ресурсов СУБД, например агрегатные результаты, основанные на других таблицах. Хранить просто сумму 2 полей одной таблицы бессмысленно, ибо даже на поддержание актуальности этой суммы (те же тригеры) нужно затратить ресурсов едва ли не больше, чем на сам расчет.

Anatoly Podgoretsky (2007-11-29 16:15:00) [8]
> Kostafey (29.11.2007 15:42:26) [26]

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

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

Stas (2007-11-29 16:13:00) [9]
sniknik © (29.11.07 15:55) [33]
индекс можно. А вот хранить результат расчета не создавая индекса нельзя :-)

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

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

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

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

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

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

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

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

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

Stas (2007-11-29 15:50:00) [15]
ну, сумма незнаю, а произведение вполне достаточно. Я думаю автор образно написал A+B

Kostafey (2007-11-29 15:49:00) [16]
> [27] KSergey © (29.11.07 15:44)

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

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

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

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

Kostafey (2007-11-29 15:45:00) [18]
> [23] KSergey © (29.11.07 15:38)

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

+1

KSergey (2007-11-29 15:44:00) [19]
> 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:42:00) [20]
> [20] Anatoly Podgoretsky © (29.11.07 15:37)

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

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

ку? :)

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

Наверх

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