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

Откуда: Москва
Сообщений: 10
Привет знатокам SQL :-)

Есть на самом деле куча вопросов по БД, поэтому букв будет много.

Суть задачи.

Есть некий прибор, который шлет измерительные данные. Например, токи, температуры, моменты и тп. Эти данные надо складировать в базу MS SQL. Ну и соответственно извлекать из нее, довольно шустро. Звучит не страшно, да?) Это если не вдаваться в детали.

Есть куча нюансов.

В среднем прибор может слать, например, 70 параметров (некоторые шлют по 50, а некоторые и больше 100). Из них, скажем, 10 времен DateTime2, 10 текстовой информации Char(50..250) и остальное – числовые данные, Float. Интенсивность поступления колеблется от раза в 10 сек до 100 раз в сек. При этом какие-то параметры могут идти, а какие-то нет. За отсутствие значения приняты String.empty для текста, Double.Min для числовых и DateTime.Min для времени. Это специфика клиентской программы. Переделыванию не подлежит.

Сервер взят 2008R2, но рассматривается вариант перехода на 2012, если это даст реальный выигрыш в производительности. Есть нюанс в том, что сервер и клиент-программа, которая принимает эти данные и кидает их в базу, находятся на одном компе. Приборов много, под каждый из них сервак не купишь. А сети между компами нет. Примите это как данность, условие задачи. Система Win7, на ней SqlServer и клиентская программа, написанная на C#, .NET4.5.

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

С записью в принципе проблем не возникает. 100 записей в сек это не нагрузка, справляется без затыков.

Веселье начинается когда надо извлечь данные. Табличка в конечном итоге состоит из интовой колонки ID записи (автоинкремент, она же primary key, кластерный), потом несколько групп параметров с временами (5 парам + текст + их время, еще 5 + текст + время, так 10 групп) и в конце несколько полей служебной информации (название прибора, имя пользователя с которого осуществлена запись и др.).

Первая колонка взята как ключ из-за специфики запросов. Поля, которые нужно запросить, выбираются пользователем. Это может быть, например, один параметр из первой группы, три из второй и два из последней + соответствующие им времена естественно, т.к. параметр без времени не имеет смысла. И какое сочетание параметров будет выбрано – непредсказуемо => проиндексировать таблицу как-то еще нереально (ну если правильно понимаю этот вопрос).

Кроме того, специфика записи такова, что как только меняются параметры в одной из групп (приходит новая порция данных с прибора), делается запись в базу с этими новыми параметрами, а в других группах остаются старые значения. Таким образом, может быть в одной из групп записана куча одинаковых значений подряд. (это издержки того, что запись в базу – суть скриншот формы в данный момент. Как только обновились параметры в одной из групп, обновляется вся форма, хотя в других группах значения старые, и делается запись в базу, поэтому все остальные группы в базе остаются со старыми параметрами).
При запросах же надо одинаковые записи объединять. Но простой distinct тут не подходит. Почему?

Допустим в базе такая картина:

IDParam1gr1Param2gr1DateTimeGr1Param1gr2Param2gr2DateTimeGr2Пояснение
1Double.MinDouble.MinDateTime.MinDouble.MinDouble.MinDateTime.MinОткрыта форма
2101513:10Double.MinDouble.MinDateTime.MinПришли данные 1 гр.
3101513:10202513:11Пришли данные гр.2; гр.1 старые
4101513:10212613:12Пришли данные гр.2; гр.1 старые
5101513:10212613:12Пришли данные в других группах; тут остались старые
6101513:10222713:13Пришли данные гр.2; гр.1 старые
7101513:10222713:14Пришли данные гр.2 такие же как предыдущие. Но в другой момент времени.
8111613:15222713:14Пришли данные гр.1; гр.2 старые
9Double.MinDouble.MinDateTime.Min222713:14Сбой по первой группе; параметры обнулились


Уникальность параметров определяется соответствующим временем. Если идут несколько одинаковых времен подряд, то однозначно параметры, соответствующие этим временам также будут одинаковы. Все эти одинаковые записи можно вывести как одну. Но если несколько одинаковых параметров подряд с разным временем, то они действительны и интересны для пользователя. Надо вывести хоть 100 одинаковых, но с разным временем.

Тут 3 варианта. Пользователь может выбрать параметр(ы) из 1 группы, из 2 и из обеих. Результаты нужны следующие: если только 1 параметр первой группы, то значения, уникальные только для него, причем исключая недействительные, т.е. с Double.Min и DateTime.Min:

IDParam1gr1DateTimeGr1
21013:10
81113:15


Если только первый параметр второй группы, соответственно
IDParam1gr2DateTimeGr2
32013:11
42113:12
62213:13
72213:14


А вот если по одному из каждой группы, то уникальность по всем группам (по сути, уникальность по временам), и исключая те записи, где все выбранные поля недействительны. Например 2 парам из 1 и 2 из 2:
IDParam2gr1DateTimeGr1Param2gr2DateTimeGr2
21513:10Double.MinDateTime.Min
31513:102513:11
41513:102613:12
61513:102713:13
71513:102713:14
81613:152713:14
9Double.MinDateTime.Min2713:14


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

Дополнительные требования к запросу: возможность условия по времени и по количеству выбранных записей как отдельно, так и совместно. Ограничение по времени накладывается на все поля времени. Если условие по количеству – то задается стартовый ID и, собственно, необходимое количество записей.

Вот теперь вроде все описал :-) кому-то может покажется так же просто, как и в начале. Вот к ним наверно и хочется обратиться за советами.

В общем виде запрос выглядит так (случай с ограничением и по количеству, и по времени, и исключая пустые записи):
SELECT DISTINCT TOP 500
	ID,
	Param2gr1,
	DateTimeGr1,
	Param2gr2,
	DateTimeGr2,
	ClientName
FROM (SELECT ID,
	Param2gr1,
	DateTimeGr1,
	Param2gr2,
	DateTimeGr2,
	ClientName,
	ROW_NUMBER()
over(partition by DateTimeGr1, DateTimeGr2 ORDER BY ID) Orden FROM tableParams) A 
WHERE (A.Orden = 1)
	AND (ID >= @iStartingID)
	AND ((DateTimeGr1 BETWEEN @tDateTimeMin AND @tDateTimeMax)
	OR (DateTimeGr2 BETWEEN @tDateTimeMin AND @tDateTimeMax))
	AND ((Param2gr1 != @cDoubleMinValue)
	OR (Param2gr2 != @cDoubleMinValue))
ORDER BY ID


Когда записей в таблице мало (~150 тыс.), запрос выполняется довольно шустро, в пределах 5 секунд. Чем больше записей, тем дольше соответственно. И на каком-то пределе выполнение запроса через SqlDataReader или SqlDataAdapter просто вываливается из 2-минутного таймаута. По сути, работа с базой становится невозможной. Писать пишется, а посмотреть уже нельзя.

Прошу совета у гуру SQL по поводу увеличения производительности запроса))

Возможно изменение самого запроса (но с сохранением результирующего набора с описанными выше условиями), индексации, архивации, настройки БД и сервера. Возможно изменение архитектуры БД, но у меня лично фантазии не хватает как логичней сделать, чем 1 прибор – 1 таблица. Записывать часто повторяющиеся данные в отдельные таблицы? Таких данных очень мало, по сравнению с общим объемом. Ну имена клиентов допустим можно выделить в отдельную, названия приборов и DateTime.Min вместе с Double.Min, и брать их оттуда а не заполнять в эту таблицу. Но тогда нужны будут JOIN’ы, и сдается мне что выгоды в данном случае они не принесут, а совсем наоборот. Сделать вместо 1 таблицы на все группы отдельно по таблице на каждую? Тоже объединять придется все равно. Или может искать не по всей таблице, а по частям, типа в первых 100 тыс, записей, потом если результатов нет или мало, смотреть вторые 100 тыс. и т.д. В общем, помогайте, коллеги.

Заранее спасибо, и тот кто осилил пост полностью и все понял – вдвойне молодец :-)
23 июл 13, 13:00    [14603688]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
Добрый Э - Эх
Guest
хвала тому, кто все твои буквы осилит...
23 июл 13, 13:12    [14603804]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
DeviceMaker
Табличка в конечном итоге состоит из интовой колонки ID записи (автоинкремент, она же primary key, кластерный), потом несколько групп параметров с временами (5 парам + текст + их время, еще 5 + текст + время, так 10 групп) и в конце несколько полей служебной информации (название прибора, имя пользователя с которого осуществлена запись и др.).
Это что, та самая табличка, в которую
DeviceMaker
схема базы максимально проста – 1 прибор – 1 таблица для него. Никаких связей. Идет трафик с прибора, пишется спокойненько в свою таблицу и никого не трогает. Подключается другой прибор – пишет в другую таблицу.
?

Как то сложновато у вас получилось :-) Отсюда и запросы сложные.
23 июл 13, 13:44    [14603995]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker,

я бы пошёл от простого к сложному, выложил бы запрос, который не проходит по таймауту и актуальный план.
23 июл 13, 13:46    [14604008]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
alexeyvg, да, та самая :-)

Звучит сложно, а выглядит не так страшно в принципе

Ну вот дополняя ту, которая была написана в первом посте как пример:

IDParam1gr1Param2gr1Text1DateTimeGr1Param1gr2Param2gr2Text2DateTimeGr2..возможно еще несколько таких групп..DeviceNameBusNameClientName


1 таблица на прибор. Для другого будут другие группы и наборы параметров, но идейно схема таблицы такая же.


_ч_, пример запроса есть в первом посте. Разве что количество параметров может отличаться, больше/меньше, суть всегда такая. Даже с одним выбранным параметром и при количестве строк в таблице ~ 1 млн. запрос будет больше 2 минут.

+План запроса
Картинка с другого сайта.

Больше всего по времени занимает сканирование индекса по колонке ID и сортировка. Знаю, что от этого можно избавиться дополнительным индексированием, но как применить его тут, когда состав запрашиваемых полей заранее не известен?
23 июл 13, 14:43    [14604500]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
Гость333
Member

Откуда:
Сообщений: 3683
DeviceMaker
Знаю, что от этого можно избавиться дополнительным индексированием, но как применить его тут, когда состав запрашиваемых полей заранее не известен?

Тут скорее не состав запрашиваемых полей важен, а условие из WHERE:
WHERE (A.Orden = 1)
	AND (ID >= @iStartingID)
	AND ((DateTimeGr1 BETWEEN @tDateTimeMin AND @tDateTimeMax)
	OR (DateTimeGr2 BETWEEN @tDateTimeMin AND @tDateTimeMax))
	AND ((Param2gr1 != @cDoubleMinValue)
	OR (Param2gr2 != @cDoubleMinValue))

@iStartingID — как определяется? Сколько записей соответствуют условию "ID >= @iStartingID"?
@tDateTimeMin, @tDateTimeMax — насколько большой этот интервал? Сколько записей туда попадают?
23 июл 13, 15:00    [14604631]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
Гость333
@iStartingID — как определяется? Сколько записей соответствуют условию "ID >= @iStartingID"?
@tDateTimeMin, @tDateTimeMax — насколько большой этот интервал? Сколько записей туда попадают?


Все эти параметры задаются пользователем на форме клиент-программы.

@iStartingID - это в 80% если влом задавать временной промежуток, и надо просто посмотреть что там в базе как пишется) чаще используется критерий времени все-таки. Но и возможность запроса по ID нужна. По нему проще ориентироваться в небольшой таблице, на несколько тысяч записей. По дефолту на форме 1, но можно менять соответственно. Сколько записей соответствуют условию "ID >= @iStartingID", зависит от размера таблицы. Если смотрим с 1 записи, а там их пара миллионов..

@tDateTimeMin, @tDateTimeMax - также задаются на форме. Ограничений нет. Можно задать неделю, и если по данному прибору за неделю ничего не записано, то ничего и не будет. А можно за сутки испытаний забить те же пару миллионов, и потом высматривать в них проскочившие ошибки или критические значения например. А ресурсные испытания это не 1 сутки мягко говоря :-)
23 июл 13, 15:30    [14604849]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker,

А выложите пожалуйста скрипт создания таблицы.
23 июл 13, 15:41    [14604928]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
А то ведь даже и не понятно какого типа у Вас колонки (если судить по таблице из первого поста с данными, то вообще все varchar или nvarchar).
23 июл 13, 15:42    [14604944]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
DeviceMaker
alexeyvg, да, та самая :-)

Звучит сложно, а выглядит не так страшно в принципе
Данные с одного прибора могут приходить произвольно, то есть не все параметры разом, в одном измерении?

И вообще, что это за сдвиги какие то???

Почему не сделать простую таблицу - параметр (группа, как вы его называете), датавремя, значение?


Что там ещё за DeviceName? значение этого поля всегда одинаково? (ведь для одного прибора своя таблица)
23 июл 13, 15:48    [14604991]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
ambarka_max
Member

Откуда: Россия
Сообщений: 517
Почему не сделать простую таблицу - параметр (группа, как вы его называете), датавремя, значение?

Тоже об этом подумалось, как-то странно а то: эти OR-ы в WHERE из-за этого
23 июл 13, 15:52    [14605030]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
Таблица создается в общем виде так.

CREATE TABLE [dbo].[deviceTM](
	[ID] [int] IDENTITY(1,1) NOT NULL,
	[Gr1_Param1] [float] NULL,
	[Gr1_Param2] [float] NULL,
	[Gr1_Param3] [float] NULL,
	[Gr1_Param4] [float] NULL,
	[Gr1_Param5] [float] NULL,
	[Gr1_Description] [char](255) NULL,
	[Gr1_Time] [datetime2](7) NULL,
	[Gr2_Param1] [float] NULL,
	[Gr2_Param2] [float] NULL,
	[Gr2_Param3] [float] NULL,
	[Gr2_Param4] [float] NULL,
	[Gr2_Param5] [float] NULL,
	[Gr2_Description] [char](255) NULL,
	[Gr2_Time] [datetime2](7) NULL,
	[Gr3_Param1] [float] NULL,
	[Gr3_Param2] [float] NULL,
	[Gr3_Param3] [float] NULL,
	[Gr3_Param4] [float] NULL,
	[Gr3_Param5] [float] NULL,
	[Gr3_Description] [char](255) NULL,
	[Gr3_Time] [datetime2](7) NULL,
	[Gr4_Param1] [float] NULL,
	[Gr4_Param2] [float] NULL,
	[Gr4_Param3] [float] NULL,
	[Gr4_Param4] [float] NULL,
	[Gr4_Param5] [float] NULL,
	[Gr4_Description] [char](255) NULL,
	[Gr4_Time] [datetime2](7) NULL,
	[Gr5_Param1] [float] NULL,
	[Gr5_Param2] [float] NULL,
	[Gr5_Param3] [float] NULL,
	[Gr5_Param4] [float] NULL,
	[Gr5_Param5] [float] NULL,
	[Gr5_Description] [char](255) NULL,
	[Gr5_Time] [datetime2](7) NULL,
	[BusName] [char](1) NULL,
	[DeviceName] [char](50) NULL,
	[DeviceAddress] [float] NULL,
	[ClientName] [char](50) NULL,
 CONSTRAINT [PK_deviceTM] PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]


alexeyvg
Данные с одного прибора могут приходить произвольно, то есть не все параметры разом, в одном измерении?


Именно. Параметры приходят по группам. Одна пришла, остальные - могут быть, а могут нет.

alexeyvg
Почему не сделать простую таблицу - параметр (группа, как вы его называете), датавремя, значение?


Результирующий набор должен выводиться в одну таблицу на форме. Если выбраны параметры из одной группы - это замечательный вариант, тогда можно обойтись и отдельными таблицами на каждую группу. А вот если из двух, то как их представить в виде лесенки, сначала один потом другой, но рядом, бок о бок? И если выбирается критерий по количеству записей, то очевидно возвращать надо ровно столько сколько задано, общее количество значащих записей по прибору, а не по группе. Иначе может быть ситуация что пользователь задал например количество 500, рядом выведены 2 группы, в первой 500 записей, во второй 100, и еще и с интервалом в месяц.

DeviceName - прибор может подключаться под разными адресами и именами соответственно. От 2 до 6 шт. BusName - шина, 2 варианта - А и В. ClientName - сколько угодно вариантов.
23 июл 13, 16:30    [14605333]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker,

если не менять структуру хранения данных и время вставки не критично, то можно попробовать сделать вот такие индексы:

CREATE NONCLUSTERED INDEX [idx_temp] ON [dbo].[deviceTM]
(
	[Gr1_Time] ASC,
	[Gr2_Time] ASC
)
INCLUDE ( 	
	[Gr1_Param1],
	[Gr2_Param1],
	[ClientName])


по группам параметров, которые используются в запросе. Ну, соответственно, время вставки должно уменьшиться, плюс индексы будут занимать дополнительное место. Идея не очень хорошая, но, честно говоря, структура Вашей таблицы тоже не ахти.
23 июл 13, 17:09    [14605594]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
_ч_
Ну, соответственно, время вставки должно увеличиться, плюс индексы будут занимать дополнительное место. Идея не очень хорошая, но, честно говоря, структура Вашей таблицы тоже не ахти.
23 июл 13, 17:10    [14605600]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
defragmentator
Member

Откуда:
Сообщений: 20504
А зачем делать длинные выборки?
Выбирайте то, сможете отобразить на экране. Обработку делайте логикой сервера.
23 июл 13, 17:34    [14605778]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker,

Кстати, поменяйте ваш запрос с Row_Number на такой:

SELECT DISTINCT TOP 500
	*
FROM (select t.ID,
	[Gr1_Param1],
	[Gr1_Time],
	[Gr2_Param1],
	[Gr2_Time],
	ClientName,
	1 as Orden from [dbo].[deviceTM] t
inner join(
select min(id) as id from [dbo].[deviceTM]
group by [Gr1_Time], [Gr2_Time])a on a.id = t.id) A 
WHERE (ID >= @iStartingID)
	AND (([Gr1_Time] BETWEEN @tDateTimeMin AND @tDateTimeMax)
	OR ([Gr2_Time] BETWEEN @tDateTimeMin AND @tDateTimeMax))
	AND (([Gr1_Param1] != @cDoubleMinValue)
	OR ([Gr2_Param1] != @cDoubleMinValue))
ORDER BY ID


Тоже должно дать прирост производительности (попробуйте без создания индексов пока)

По сути, два запроса возвращают одно и тоже, но второй должен быть быстрее:
select * from (SELECT  ID,
	[Gr1_Param1],
	[Gr1_Time],
	[Gr2_Param1],
	[Gr2_Time],
	ClientName,
	ROW_NUMBER()
over(partition by [Gr1_Time], [Gr2_Time] ORDER BY ID) Orden FROM [dbo].[deviceTM]
)a
where 
orden = 1

select t.ID,
	[Gr1_Param1],
	[Gr1_Time],
	[Gr2_Param1],
	[Gr2_Time],
	ClientName,
	1 as Orden from [dbo].[deviceTM] t
inner join(
select min(id) as id from [dbo].[deviceTM]
group by [Gr1_Time], [Gr2_Time])a on a.id = t.id
23 июл 13, 17:42    [14605850]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
_ч_, я пробовал делать индексы по сочетаниям групп на колонки ID и времени, прирост это дает, да, но все сочетания не охватить.. Если групы 3, то это уже 7 индексов, а если больше - то ужас :-)

С запросом попробую, доложу о результатах) Спасибо!
23 июл 13, 18:05    [14606015]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
defragmentator, по результирующим данным потом строится график. И вот на нем можно и нужно отобразить гораздо больше, чем помещается на экране.
23 июл 13, 18:07    [14606025]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker,

ужас, согласен. Но я другого выхода (кроме изменения структуры) не вижу больше.
23 июл 13, 18:08    [14606033]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
DeviceMaker
А вот если из двух, то как их представить в виде лесенки, сначала один потом другой, но рядом, бок о бок?
Во первых, любую выборку можно представить хоть в виде полупрозрачного трёхмерного шара, какие проблемы?

А если хочется, что бы результат запроса непременно соответствовал виду таблицы на экране, то можно делать джойны (по количеству параметров) либо использовать UNPIVOT.

Но конечно самый правильный первый вариант, то есть отображением занимается клиент.
23 июл 13, 18:13    [14606057]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
_ч_
Кстати, поменяйте ваш запрос с Row_Number на такой: ...


Поменял, потестил, в среднем замена запроса дает 25% прирост скорости. Это оч радует :-) Спасибо большое! Картинка с другого сайта.

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


Ну изменение структуры вполне возможно, только вот сложность ее реализации велика. Ну для меня, честно говоря) я вообще знакомство с БД начал сразу с этой задачи, и за год вот пока только такие результаты. Попробую через некоторое время разделить большую таблицу на таблицы по группам, но пока слабо себе представляю как к этому подступиться с точки зрения запросов и клиента.. Надо думать :-)

alexeyvg
любую выборку можно представить хоть в виде полупрозрачного трёхмерного шара


Можно-то можно, знать бы как)) пошел в гугл прокачивать свое кунг-фу и читать про pivot.
24 июл 13, 14:33    [14610676]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
_ч_
Member

Откуда:
Сообщений: 1446
DeviceMaker
Ну изменение структуры вполне возможно, только вот сложность ее реализации велика. Ну для меня, честно говоря) я вообще знакомство с БД начал сразу с этой задачи, и за год вот пока только такие результаты. Попробую через некоторое время разделить большую таблицу на таблицы по группам, но пока слабо себе представляю как к этому подступиться с точки зрения запросов и клиента.. Надо думать :-)


Советую Вам сделать одну таблицу с параметрами, а в ней ввести дополнительный признак (например, числовой) к какой группе относиться параметр.
Тогда Ваш запрос трансформируется в запрос select - join (ну, возможно нужно будет сделать unpivot) и будет значительно шустрее.
24 июл 13, 14:40    [14610752]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
DeviceMaker
Member

Откуда: Москва
Сообщений: 10
_ч_
Советую Вам сделать одну таблицу с параметрами, а в ней ввести дополнительный признак (например, числовой) к какой группе относиться параметр.

Не совсем понял.. Т.е. большую таблицу со всеми данными не трогать, а сделать дополнительную с признаками того, какая колонка большой таблицы относится к какой-либо группе?
24 июл 13, 14:46    [14610814]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
DeviceMaker
alexeyvg
любую выборку можно представить хоть в виде полупрозрачного трёхмерного шара


Можно-то можно, знать бы как))
Что тут прокачивать? Просто программировать надо. Ну вот в какой нибуть сетевой игре данные храняться на сервере в СУБД в виде таблиц, а на экране у игрока монстры бегают, и без всяких UNPIVOT. Вот как то так...
DeviceMaker
Попробую через некоторое время разделить большую таблицу на таблицы по группам, но пока слабо себе представляю как к этому подступиться с точки зрения запросов и клиента.. Надо думать :-)
Не надо разделять на таблицы по группам, нужно делать одну таблицу:

ID параметра
Время
Значение

Или даже одну таблицу на все приборы:
ID прибора
ID параметра
Время
Значение
24 июл 13, 14:52    [14610895]     Ответить | Цитировать Сообщить модератору
 Re: Повышение скорости выполнения запроса  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31948
DeviceMaker
Ну для меня, честно говоря) я вообще знакомство с БД начал сразу с этой задачи, и за год вот пока только такие результаты.
Вообще год слишком много для освоения работы с СУБД.

ИМХО ваша ошибка в том, что вы много программируете, и мало читаете теорию и учебники, а поначалу нужно наоборот.

Вот тут есть форум Проектирование БД, нужно побольше там читать и спрашивать, а оптимизация и тонкости построения запросов конкретно в MS SQL Server дело вторичное.
24 июл 13, 14:56    [14610943]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить