Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 оцените подход хранения параметров  [new]
undefined_user
Guest
MS SQL Server 2012

концептуальный код:

+
-------------------------------------------------------------------------------------------------------------------
create schema [sys_context]
go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create table [sys_context].[parameter]
(
	[id_parameter]		[int] IDENTITY(1,1)			not null 
	
	, constraint [pk_sys_context_parameter] primary key clustered ([id_parameter])

	, [name]			[nvarchar](200)				not null

	, constraint [un_sys_context_parameter] unique nonclustered ([name])

	, [type]			[nvarchar](10)				not null default N'C100'				
			-- тип параметра, предполагается, что типы могут быть следующие:
			-- N - числа, 
			-- D - дата, 
			-- CХХ - строка символов,
			-- где ХХ - максимальная длинна строки, типы нужны только для пользовательского интерфейса

	, [value]			[nvarchar](1000)			not null
)
go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create function [sys_context].[get_string]
(
	@name nvarchar(200)
)
returns nvarchar(1000)
begin
	return (select [p].[value] from [sys_context].[parameter] [p] where [p].[name] = @name)
end
Go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create function [sys_context].[get_date]
(
	@name nvarchar(200)
)
returns date
begin
	return (CONVERT (date, [sys_context].[get_string] (@Name), 104))
end
Go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create Function [sys_context].[get_float]
(
	@name nvarchar(200)
)
returns float
begin
	return (CONVERT (float, [sys_context].[get_string] (@name)))
end
Go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create function [sys_context].[get_numeric]
(
	@name nvarchar(200)
)
returns numeric(25, 5)
begin
	return (CONVERT (numeric(25, 5), [sys_context].[get_string] (@name)))
end
Go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create view [dbo].[my_test_view]
as
select
	[tt].[id]
	, [tt].[op_day]
	, [tt].[op_kind]
	, [tt].[op_cash]
from
	[dbo].[test_table] [tt]
where
	(1 = 1)
	and [tt].[op_day] >= [sys_context].[get_date] (N'beg_day')
	and [tt].[op_day] <= [sys_context].[get_date] (N'end_day')
	and [tt].[op_cash] >= [sys_context].[get_numeric] (N'cash_limit')

go
-------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------
create procedure [dbo].[my_test_proc]
as
begin
	set nocount on;

	declare @beg_day		date			= [sys_context].[get_date] (N'beg_day');
	declare @end_day		date			= [sys_context].[get_date] (N'end_day');
	declare @cash_limit		numeric(25,2)	= [sys_context].[get_numeric] (N'cash_limit');

	-- какая-то обработка ...
end
go
-------------------------------------------------------------------------------------------------------------------



механизм работы такой:
- таблица [sys_context].[parameter] заполняется некоторым набором параметров и предустановленными значениями параметров
- пользователи через клиентское приложение меняют параметры в [sys_context].[parameter]
- пользователи через клиентское приложение выполняют [dbo].[my_test_view] и [dbo].[my_test_proc] и получают результаты
- предполагается, что пользователь один, если их станет больше, то можно в [sys_context].[parameter] добавить id пользователя и изменить [sys_context].[get_string]

как определить насколько это повлияет на производительность представления, сколько раз оптимизатор решить выполнить функции?

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

какие минусы у подхода?
может есть другие решения, чтобы свой велосипед не собирать?
9 авг 13, 10:46    [14685456]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
aleks2
Guest
1.
[value]			[nvarchar](1000)


sql_variant

круче будет.


2. В этом баяне самое трудное - идентификация СЕССИИ. Ибо клиенты могут отрывать множество подключений, даже не подозревая о том...
9 авг 13, 10:59    [14685586]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
undefined_user,

про концепцию пока промолчу, а вот скалярные функции - это полный отстой и отличные тормоза.
Переделайте на табличные in-line функции (они ведь могут же возвращать одну строку с одной колонкой!).
9 авг 13, 11:00    [14685594]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Glory
Member

Откуда:
Сообщений: 104751
Т.е. перед каждым отчетом нужно помнить, какие последние параметры были для него внесены ?
Или будет хранится вся история параметров ?



undefined_user
как определить насколько это повлияет на производительность представления, сколько раз оптимизатор решить выполнить функции?

скалярную deterministic функцию оптимизатор выполнит нужное число раз
9 авг 13, 11:01    [14685607]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Безумству храбрых - венки со скидкой
По сабжу - нет я знаю много методов как похоронить проект , но сие looks like this
#define TRUE FALSE
9 авг 13, 11:12    [14685692]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34706
undefined_user,

насколько это повлияет на производительность представления, сколько раз оптимизатор решить выполнить функции?

Это как раз совсем не важно, сколько вызываться будет функция.
9 авг 13, 11:54    [14686027]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Glory
Т.е. перед каждым отчетом нужно помнить, какие последние параметры были для него внесены ?
Или будет хранится вся история параметров ?


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

Glory
скалярную deterministic функцию оптимизатор выполнит нужное число раз

это число можно определить?
если он каждый раз будет дергать функцию возвращающую дату, при выборке данных из таблички в которой сейчас 400+ млн. записей, то понятно, что я собрался реализовать бредовую идею.
а если он выполнить функцию один раз ...
9 авг 13, 11:59    [14686060]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
MasterZiv
undefined_user,

насколько это повлияет на производительность представления, сколько раз оптимизатор решить выполнить функции?

Это как раз совсем не важно, сколько вызываться будет функция.


т.е. затратами на вызов функции можно пренебречь?
9 авг 13, 12:01    [14686085]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34706
undefined_user,

Давай пойдем от обратного.
Метод классный, спору нет. Только что конкретно ты выиграешь?

Запросы писать надо, каждый параметр в них вписывать надо, экономия только на редактировании параметров на клиенте.

Но передача параметров через контекст мало дает преимуществ перед передачей из напрямую в процедуры, если ты вызываешь ее непосредственно.
(если опосредовано — там дело совсем другое ).

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

Все будет то же самое, но не будет использования контекста сессии.
9 авг 13, 12:08    [14686132]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34706
Maxx
Безумству храбрых - венки со скидкой
По сабжу - нет я знаю много методов как похоронить проект , но сие looks like this
#define TRUE FALSE



Да ладно, человек нормальный отчетник делает.
9 авг 13, 12:10    [14686146]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Glory
Member

Откуда:
Сообщений: 104751
undefined_user
Glory
Т.е. перед каждым отчетом нужно помнить, какие последние параметры были для него внесены ?
Или будет хранится вся история параметров ?


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

Как это не надо ? Я иду в пункт формирования отчета, получаю его и тут замечаю, что он построен по критериям, которые мне не нужны

undefined_user
Glory
скалярную deterministic функцию оптимизатор выполнит нужное число раз

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


Deterministic functions always return the same result any time they are called with a specific set of input values and given the same state of the database.
Зачем оптимизатору вызывать детерминированную функцию с постоянным параметром 400млн раз ?
А вот сможите ли вы сделать эту функцию детерминированной - это вопрос
9 авг 13, 12:11    [14686153]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
werfqfwfwqef
Guest
iap
undefined_user,

про концепцию пока промолчу, а вот скалярные функции - это полный отстой и отличные тормоза.
Переделайте на табличные in-line функции (они ведь могут же возвращать одну строку с одной колонкой!).


+100 к IVTF
9 авг 13, 12:13    [14686162]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
MasterZiv
undefined_user,

Давай пойдем от обратного.
Метод классный, спору нет. Только что конкретно ты выиграешь?

Запросы писать надо, каждый параметр в них вписывать надо, экономия только на редактировании параметров на клиенте.

Но передача параметров через контекст мало дает преимуществ перед передачей из напрямую в процедуры, если ты вызываешь ее непосредственно.
(если опосредовано — там дело совсем другое ).

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

Все будет то же самое, но не будет использования контекста сессии.


у меня уже есть приложением для работы с базой данных, оно формирует свой интерфейс на основании данных из бд, там реализовано несколько форм, основные браузер - для просмотра результатов запросов и форма для выполнения операций, которая умеет выполнять хранимые процедуры, но их результат выводить не умеет :-(
в это приложение я не буду добавлять формы под конкретные операции, поэтому нужно будет писать еще одно приложение, а этого делать не хочется, и времени потребуется больше.
в имеющееся приложением я могу легко встроить контекст, в принципе основной вопрос в производительности, ну и возможно ввиду отсутствия опыта я не вижу куда могу вляпаться.
9 авг 13, 12:41    [14686339]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Glory
Как это не надо ? Я иду в пункт формирования отчета, получаю его и тут замечаю, что он построен по критериям, которые мне не нужны


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

ходить ни куда не надо.
9 авг 13, 12:49    [14686402]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Glory
Member

Откуда:
Сообщений: 104751
undefined_user
не-не, все гораздо проще, сидит у меня сотрудник, которого я торжественно назначил ответственным за этот отчет, выдал нормативные документы и прочие указания, показал как формировать отчет, объяснил, что его нужно делать 1 раз в неделю, например каждый вторник, потом анализировать до четверга, выясняя подробности, потом показывать мне, а после моего утверждения размещать на корпоративном портале в соответствующем разделе.
так вот, если он будет формировать отчеты используя не те параметры, то это будут его личные проблемы.
основные параметры там кстати это период, а коэффициенты, стоимости транзакций, они могут меняться со временем, но я думаю не реже чем раз в квартал, т.е. ошибку допустить можно, но сложно.

ходить ни куда не надо.

В чем тогда смысл хранения параметров в базе ?
9 авг 13, 12:50    [14686416]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Glory
В чем тогда смысл хранения параметров в базе ?


у меня так устроенно приложение, я не хочу писать новое, хотел найти решение для существующего.
суть не в хранении параметров, а в их передаче в представление или функцию.
9 авг 13, 13:02    [14686498]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Glory
Member

Откуда:
Сообщений: 104751
undefined_user
у меня так устроенно приложение, я не хочу писать новое, хотел найти решение для существующего.
суть не в хранении параметров, а в их передаче в представление или функцию.

Ничего не понял
Приложение не умеет передавать параметры из своего интерфейса ?
9 авг 13, 13:06    [14686520]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Glory
undefined_user
у меня так устроенно приложение, я не хочу писать новое, хотел найти решение для существующего.
суть не в хранении параметров, а в их передаче в представление или функцию.

Ничего не понял
Приложение не умеет передавать параметры из своего интерфейса ?


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

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

если подход с контекстом плохой, то проще написать отдельное приложение и запустить эту задачу.
9 авг 13, 13:18    [14686590]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Раз уж пошел разговор за концепции, прокомментируйте такую идею.

1) Все параметры хранимок\функций делаем XML в формате Key=Value
2) Пишем некий код, который поднимает значение по имени

Все хранимки/функции тогда приобретают такой вид

CREATE PROC MySuperProc @XMLParams 

AS
.... 
SET  @SomeVarchar =  GetVarchar(@XMLParams, 'Parname1')
SET  @SomeDate      =  GetDate(@XMLParams, 'Parname2')


Ну и понятно, что параметры в таком виде очень легко хранить в таблах, чтоб, например запоминать настройки пользователя. Удобно совать между процками, когда речь идет о "наследовании " сущностей ( тут я подразумеваю, что в нашей мегагсистеме есть некая объектная надстройка") и тому подобное.
9 авг 13, 13:42    [14686769]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
>GetDate(@XMLParams, 'Parname2')
GetSomeDate(@XMLParams, 'Parname2')
9 авг 13, 13:45    [14686810]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Может существует какой-то стандартный механизм воздать набор параметров для сеанса или для пользователя, чтобы можно было потом использовать в представлениях, функциях и процедурах?
9 авг 13, 13:52    [14686876]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
undefined_user
Guest
Cammomile
Раз уж пошел разговор за концепции, прокомментируйте такую идею.

1) Все параметры хранимок\функций делаем XML в формате Key=Value
2) Пишем некий код, который поднимает значение по имени

Все хранимки/функции тогда приобретают такой вид

CREATE PROC MySuperProc @XMLParams 

AS
.... 
SET  @SomeVarchar =  GetVarchar(@XMLParams, 'Parname1')
SET  @SomeDate      =  GetDate(@XMLParams, 'Parname2')


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


а что будет в представлении?
9 авг 13, 13:55    [14686915]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Glory
Member

Откуда:
Сообщений: 104751
undefined_user
Может существует какой-то стандартный механизм воздать набор параметров для сеанса или для пользователя, чтобы можно было потом использовать в представлениях, функциях и процедурах?

Стандатного не существует.
Передача параметров через таблицу - нормальная реализация
Про производительность функций вам уже сказали
9 авг 13, 13:56    [14686922]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Стандартный ето - дефолтовые параметре в SSRS которые возращаються ф-цией на основании логина пользователя, вот сначала их читайте,а патом вызывайте отчет
Храние в виде записей в таблице где ключ,имя репорта +логин (как вариант)
9 авг 13, 13:57    [14686938]     Ответить | Цитировать Сообщить модератору
 Re: оцените подход хранения параметров  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
Cammomile,
получается что "прослушивание" параметров оптимизатором в таком случае не будет работать.
9 авг 13, 13:58    [14686942]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить