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

Откуда:
Сообщений: 7
Есть MS SQL 2005 Std.
Есть таблица, хранящая изменения, допустим, остатков в разрезе товаров и складов на дату (Товар, Склад, Дата, Остаток).

Товаров много, складов тоже не мало, период хранения данных тоже большой.

Вариант 1: если хранить только остатки на даты их изменения, таблица содержит около миллиона записей и занимает 30 Мб, что отлично.

Вариант 2: если хранить остаток по каждому товару и складу на каждый день, вне зависимости от того, меняется ли в этот день остаток или остаётся как на вчера, таблица вырастает до неприличных 30 Гб, т.е. примерно на 3 порядка. Это много, с учетом того, что фактических данных у нас остаётся столько же, плюс, при изменении значения в одной дате, придется обновлять последующие.

Задача же решаемая этой таблицей, джойнить её к большим табличным частям документов, на лету получая остаток по товару и складу на дату.

Если джойнить к таблице по варианту 2 - всё джойнится быстро (точное соответствие, индексы делают своё дело).

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

Вопрос: каким образом тут можно обеспечить компромисс между объемом данных и скоростью получения данных на произвольную дату?
6 май 15, 15:24    [17607915]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Aclz, Вы можете получить остаток на любой день суммируя приход-расход с группировкой по товару, учитывая дату изменения. Сомневаюсь, что такой запрос выполняится медленно.
6 май 15, 16:29    [17608393]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
MSSQLBug
Guest
Aclz
Есть MS SQL 2005 Std.
Есть таблица, хранящая изменения, допустим, остатков в разрезе товаров и складов на дату (Товар, Склад, Дата, Остаток).

Товаров много, складов тоже не мало, период хранения данных тоже большой.

Вариант 1: если хранить только остатки на даты их изменения, таблица содержит около миллиона записей и занимает 30 Мб, что отлично.


У нас есть такая схема хранения остатков, я сейчас выполнил:
SELECT COUNT(*) FROM [таблица_с_остатками_на_даты_их_изменения]

И получил: 45971909


Aclz
Если джойнить к таблице по варианту 1, то напрямую джойнить не удаётся (т.к. есть даты, в которых остатки не изменялись, значит, таких записей в таблице нет, их приходится получать из последнего на дату предыдущего значения остатка), приходится писать либо вьюху, которая превращает из таблицы по варианту 1 таблицу по варианту 2, что работает очень долго, либо писать фукнции, что работает также долго.

Вопрос: каким образом тут можно обеспечить компромисс между объемом данных и скоростью получения данных на произвольную дату?


Я попробовал на наших данных написать аналогичный запрос для документа с 5000-ми товаров, и отрабатывает это меньше секунды, и план вполне приемлемый. Так что покажите, пожалуйста, структуру Ваших таблиц, запросы, View-ы, функции...
6 май 15, 16:52    [17608605]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
хе-хе )
Guest
Материализованые (индексированые) представления?
6 май 15, 17:25    [17608845]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
Aclz
Member

Откуда:
Сообщений: 7
Владислав Колосов
Aclz, Вы можете получить остаток на любой день суммируя приход-расход с группировкой по товару, учитывая дату изменения. Сомневаюсь, что такой запрос выполняится медленно.

У меня даже проще, не обороты, а на даты изменения хранятся сами конечные остатки. Скажем, в месяце товар пришел 1го числа в количестве 10 штук, 10го в кол-ве 10, и 20го тоже в количестве 10 штук. В таблице будут три записи по товару: 1е число - 10, 10е - 20, 20е - 30. Если надо получить остаток на 15е - нужно найти запись, соответствующую в данном случае 10му числу, как последнему предшествующему 15му. Для этого используются разные конструкции языка, которые на одном товаре отрабатывают мгновенно, а, скажем, на массиве документов из 10000 товаров по 50 складам на периоде месяц - полный швах.

MSSQLBug
У нас есть такая схема хранения остатков, я сейчас выполнил:
SELECT COUNT(*) FROM [таблица_с_остатками_на_даты_их_изменения]

И получил: 45971909
Я попробовал на наших данных написать аналогичный запрос для документа с 5000-ми товаров, и отрабатывает это меньше секунды, и план вполне приемлемый. Так что покажите, пожалуйста, структуру Ваших таблиц, запросы, View-ы, функции...


Упрощу пример по-максимуму (убрав лишние поля, индексы и пр.).

Допустим, таблица следующая:

CREATE TABLE Остатки
    (
    Товар char(9),
    Дата datetime,
    Остаток int
    )


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

Через max(Дата):
--Получаем даты последних установленных остатков, не превосходящие выбранную дату, и берем остатки на эти даты
select
    t.Товар,
    t.Остаток
from
    Остатки t
    join
    (
    select
        Товар,
        max(Дата) Дата
    from
        Остатки
    where
        Дата <= '20140101'
    group by
        Товар
    ) sq
        on sq.Товар = t.Товар
        and sq.Дата = t.Дата


Или через row_number():
--Вводим row_number c partition по товару и обратной сортировкой по дате, во внешнем запросе фильтруем по row_number() = 1
select
    Товар,
    Остаток
from
    (
    select
        Товар,
        Дата,
        row_number() over (partition by Товар order by Дата desc) as row,
        value
    from
        Остатки
    where
        Дата <= '20140101'
    ) sq
where
    row = 1


Ну и самое неоптимальное:

--Решаем в лоб
select
    Товар,
    (
    select top 1
        r1.value
    from
        Остатки r1
    where
        r1.Товар = r.Товар
        and r1.Дата <= '20140101'
    order by
        r1.Дата desc
    ) as Остаток
from
    Остатки r



(В реальности из измерений есть еще склад).

Первые два запроса на конкретной дате отрабатывают приемлемо. Но если нужно получить остатки по произвольному множеству товаров и складов на каждый день за период в несколько месяцев, то тут отставание в скорости от варианта 2 (где остатки хранятся на каждую дату вне зависимости от наличия изменений) становится очень существенным из-за вот этого поиска последнего значения на дату.
6 май 15, 17:58    [17609063]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
Aclz
Member

Откуда:
Сообщений: 7
хе-хе )
Материализованые (индексированые) представления?

Как ни крутил, на практике упирался в многочисленные ограничения при их создании (плюс, если делать таблицу по варианту 1, а на ней материализованный индекс, реализующий вариант 2, индекс всё равно выйдет многогигабайтный).
6 май 15, 18:00    [17609088]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Aclz
Вопрос: каким образом тут можно обеспечить компромисс между объемом данных и скоростью получения данных на произвольную дату?


Я только что занимался этой задачей. Компромис такой

1) SQL 2014 (ниже никак)
2) ColumnStore Index
3) Партиционирование по датам (дням)

Результат
1) Быстро заполняется за конкретную дату
2) Занимает меньше места (у меня в 8 раз)
3) Быстро выдаёт результат при фильтре по дате (не медленнее, чем полная таблица)
6 май 15, 18:36    [17609279]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
compresson
Guest
А если апгрейдить до 2008 Enterprise Edition и применить page compression то сколько будет размер таблицы 2?
6 май 15, 19:14    [17609450]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
MSSQLBug
Guest
Aclz
Для этого используются разные конструкции языка, которые на одном товаре отрабатывают мгновенно, а, скажем, на массиве документов из 10000 товаров по 50 складам на периоде месяц - полный швах.

Ради интереса, а зачем Вам это (я понимаю вариант отображения остатков в одном документе, а в массиве-то зачем)?

Aclz
Упрощу пример по-максимуму (убрав лишние поля, индексы и пр.).

А вот это зря, IMHO, лучше бы Вы его, наоборот, к реальной структуре приблизили (особенно индексы, да и поле "склад" вряд ли тут лишнее).

Aclz
CREATE TABLE Остатки
    (
    Товар char(9),
    Дата datetime,
    Остаток int
    )


Придирка: почему datetime, а не date?

Aclz
Для этого можно использовать следующие конструкции:
...
Первые два запроса на конкретной дате отрабатывают приемлемо.


Кстати, на нашей [таблица_с_остатками_на_даты_их_изменения] ;) ни один из приведённых запросов быстро не отрабатывает. Для таких целей у нас есть ещё таблица с ежемесячными срезами остатков (как в 1С) + таблица движений. Запросы, правда, немного посложнее, но и производительность гораздо лучше.

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


Так Вы эти-то запросы и покажите! ;) Как у Вас выбираются эти множества товаров и складов? А получение остатков "на каждый день за период в несколько месяцев" --- это же совсем другая задача, она фактически требует материализации варианта 2 в результате запроса! Зачем это Вам, опять-таки?
6 май 15, 19:23    [17609484]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
compresson
Guest
Надеюсь индекс (Товар, Склад, Дата), покрывает Остаток?
6 май 15, 20:00    [17609596]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
MSSQLBug
Придирка: почему datetime, а не date?


Почему вообще не INT 20150316 ?
6 май 15, 20:14    [17609636]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
a_voronin
MSSQLBug
Придирка: почему datetime, а не date?


Почему вообще не INT 20150316 ?
Зачем INT, а не DATE? Профит в чём?
Aclz
Если джойнить к таблице по варианту 1, то напрямую джойнить не удаётся (т.к. есть даты, в которых остатки не изменялись, значит, таких записей в таблице нет, их приходится получать из последнего на дату предыдущего значения остатка), приходится писать либо вьюху, которая превращает из таблицы по варианту 1 таблицу по варианту 2, что работает очень долго, либо писать фукнции, что работает также долго.

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

Если частая, тыща запросов в секунду, то лучше материализовать; пусть будет большой объём, 30 гб - это немного.
MSSQLBug
Так Вы эти-то запросы и покажите! ;) Как у Вас выбираются эти множества товаров и складов? А получение остатков "на каждый день за период в несколько месяцев" --- это же совсем другая задача, она фактически требует материализации варианта 2 в результате запроса! Зачем это Вам, опять-таки?
+1
6 май 15, 21:11    [17609803]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
Aclz
Member

Откуда:
Сообщений: 7
a_voronin
1) SQL 2014 (ниже никак)

compresson
А если апгрейдить до 2008 Enterprise Edition

Апгрейдить будем, если поймем, что на имеющемся софте никак.

MSSQLBug
Ради интереса, а зачем Вам это (я понимаю вариант отображения остатков в одном документе, а в массиве-то зачем)?

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

автор
А вот это зря, IMHO, лучше бы Вы его, наоборот, к реальной структуре приблизили (особенно индексы, да и поле "склад" вряд ли тут лишнее).

Там такой клубок лапши всего всякого, что вряд ли кто-то захочет в это погружаться.
MSSQLBug
Придирка: почему datetime, а не date?

Дык:
Aclz
Есть MS SQL 2005 Std.


MSSQLBug
Кстати, на нашей [таблица_с_остатками_на_даты_их_изменения] ;) ни один из приведённых запросов быстро не отрабатывает. Для таких целей у нас есть ещё таблица с ежемесячными срезами остатков (как в 1С) + таблица движений. Запросы, правда, немного посложнее, но и производительность гораздо лучше.

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

Счас тестирую вычитанный вариант, когда в таблицу в пару к полю Дата добавляется поле ДатаКон, дата окончания действия записи (т.е. после которой существует новая запись по этим измерениям). Пересчитывать в таком варианте нужно куда меньше, чем в варианте с итогами (можно даже, наверное, попробовать заполнять это поле по триггеру), зато вместо хитрых условий в запросе и подзапросов, можно явно писать
where '20140101' between tab.Дата and tab.ДатаКон


Если не взлетит, вывалю сюда реальные запросы.
6 май 15, 22:23    [17610024]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
MSSQLBug
Guest
a_voronin
MSSQLBug
Придирка: почему datetime, а не date?


Почему вообще не INT 20150316 ?

А зачем?

data type storage size
int 4 Bytes
date 3 bytes, fixed
6 май 15, 22:24    [17610029]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
MSSQLBug
Guest
Aclz
Вообще остатки были упомянуты для простоты примера, на деле там не остатки, а различные виды нормативной себестоимости, считающейся по множеству различных показателей. Потом она умножается на обороты и получаем обороты в этой себестоимости.

Так Вы приведите такие примеры, советы по которым потом сможете применить к своей реальной ситуации, а то Вы как-то слишком упрощаете, как мне кажется. А то Вам сейчас надают советов, а в реальности применить их не получится, и всё опять пойдёт по кругу. :(

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

А если лапшу отрезать, суть оставить? ;)

MSSQLBug
Придирка: почему datetime, а не date?

Дык:
Aclz
Есть MS SQL 2005 Std.

Упс, забыл... :( Тогда почему не smalldatetime? ;)

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

Это да (триггеры решают эту проблему, но они получаются не очень простые).

Aclz
Счас тестирую вычитанный вариант, когда в таблицу в пару к полю Дата добавляется поле ДатаКон, дата окончания действия записи (т.е. после которой существует новая запись по этим измерениям). Пересчитывать в таком варианте нужно куда меньше, чем в варианте с итогами (можно даже, наверное, попробовать заполнять это поле по триггеру), зато вместо хитрых условий в запросе и подзапросов, можно явно писать
where '20140101' between tab.Дата and tab.ДатаКон


Если не взлетит, вывалю сюда реальные запросы.

Предрекаю, что не взлетит (по крайней мере, намного лучше не станет). ;) Подумайте над таким вопросом: какой индекс и как сервер сможет использовать для поиска по этому условию?
И, кстати, триггеры заполнения этого поля тоже сложнее, чем кажутся (можно феерично накосить, как мне однажды удалось ;) ).

IMHO, по текущему состоянию дискуссии Вы даже не сформулировали конкретного вопроса (и запросов), поэтому врядли Вам что-то конкретное посоветуют...
6 май 15, 22:42    [17610080]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
invm
Member

Откуда: Москва
Сообщений: 9406
Aclz
Счас тестирую вычитанный вариант, когда в таблицу в пару к полю Дата добавляется поле ДатаКон, дата окончания действия записи (т.е. после которой существует новая запись по этим измерениям). Пересчитывать в таком варианте нужно куда меньше, чем в варианте с итогами (можно даже, наверное, попробовать заполнять это поле по триггеру), зато вместо хитрых условий в запросе и подзапросов, можно явно писать
where '20140101' between tab.Дата and tab.ДатаКон
Это вам для анализа и размышлений:
+
use tempdb;
go

create table dbo.t1 (t1_id int identity primary key, v int);
create table dbo.t2 (t2_id int identity primary key, t1_id int not null, vs int, ve int, a int);
create index IX_t2__t1_id__vs__ve on dbo.t2 (t1_id, vs, ve) include (a);

insert into dbo.t1
 (v)
 select top (10000)
  rand(checksum(newid())) * 1000 + 1
 from
  master.dbo.spt_values a cross join
  master.dbo.spt_values b;

insert into dbo.t2
 (t1_id, vs, ve, a)
 select
  t1.t1_id, x.vs, x.ve, x.a
 from
  dbo.t1 cross apply
  (select top (t1.v / 5 + 1) (row_number() over (order by (select 1)) - 1) * 5 + 1, row_number() over (order by (select 1)) * 5, rand(checksum(newid())) * 100 from master.dbo.spt_values) x(vs, ve, a)
go

declare @a int;

set statistics xml, io, time on;

select
 @a = t2.a
from
 dbo.t1 join
 dbo.t2 on t2.t1_id = t1.t1_id and t1.v between t2.vs and t2.ve
option
 (maxdop 1);

select
 @a = t2.a
from
 dbo.t1 join
 dbo.t2 on t2.t1_id = t1.t1_id and t1.v between t2.vs and t2.ve
option
 (maxdop 1, loop join);

select
 @a = t2.a
from
 dbo.t1 cross apply
 (select top (1) a from dbo.t2 where t1_id = t1.t1_id and vs <= t1.v order by vs desc) t2(a)
option
 (maxdop 1);

set statistics xml, io, time off;
go

drop table dbo.t1, dbo.t2;
go
6 май 15, 23:24    [17610176]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
SERG1257
Member

Откуда:
Сообщений: 2752
Aclz
Вопрос: каким образом тут можно обеспечить компромисс между объемом данных и скоростью получения данных на произвольную дату?
Лобовое решение типа анализировать входные данные (например, даты) и материализовать только для популярных, критических запросов, полагаю уже рассматривали (редкие запросы к старым данным пусть идут по медленному пути)
Aclz
Апгрейдить будем, если поймем, что на имеющемся софте никак
С 2005 придется слезать по-любому ибо поддержка кончится. В новых версиях будет проще боротся с большими таблицами (как минимум бакап можно сжимать в SE)
Таблицу можно заменить на вьюху чтобы было легче удалять старые данные.
https://msdn.microsoft.com/en-us/library/ms190019.aspx

MSSQLBug
Подумайте над таким вопросом: какой индекс и как сервер сможет использовать для поиска по этому условию?
Товар, Склад, ДатаКон.
Открытую дату заполнять датой в будущем '9999'. Тогда самый популярный запрос на текущую дату будет поэффективнее.
6 май 15, 23:51    [17610219]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Хранить остатки как раз плохо, т.к. для их обработки потребуется сортировка всей таблицы, это дорогая операция. Если бы Вы хранили дельты, то выполнили бы скан и агрегацию, что заметно дешевле.
7 май 15, 12:18    [17612077]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
compresson
А если апгрейдить до 2008 Enterprise Edition и применить page compression то сколько будет размер таблицы 2?


Пробовал, плохая идея. Положит процессор.
7 май 15, 13:37    [17612673]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
MSSQLBug
Guest
invm
Это вам для анализа и размышлений:

А вот ещё (на реальных данных, о которых я уже говорил):

DECLARE @Date AS smalldatetime, @DateStartMonth AS smalldatetime
SET @Date = '20150228'

--- Первый запрос:
SELECT r.ItemId, r.InventLocationId, r.RestQ
  FROM [таблица_с_остатками_на_даты_их_изменения] AS r
 INNER JOIN (
       SELECT InventLocationId, ItemId, max(RDate) AS MaxDate
         FROM [таблица_с_остатками_на_даты_их_изменения] AS r1
        WHERE r1.RDate <= @Date
        GROUP BY InventLocationId, ItemId
        ) AS MaxDates
    ON r.ItemId = MaxDates.ItemId AND r.RDate = MaxDates.MaxDate
   AND r.InventLocationId = MaxDates.InventLocationId
 WHERE r.RestQ <> 0

-- Второй запрос:
SET @DateStartMonth = DATEADD(month, DATEDIFF(month, 0, @Date), 0)
SET @DateStartMonth = (SELECT CASE WHEN MAX(RDate) < @DateStartMonth
                              THEN max(RDate)
                              ELSE @DateStartMonth END
                         FROM dbo.[Таблица_ежемесячных_срезов_остатков])

SELECT InventLocationId, ItemId, SUM(TurnQty) AS RestQ
  FROM (
       -- Остатки на утро начала месяца:
       SELECT ItemId, InventLocationId, RestQ AS TurnQty
         FROM dbo.[Таблица_ежемесячных_срезов_остатков] AS r
        WHERE r.RDate = @DateStartMonth
        UNION ALL
       -- Движения за период от начала месяца до нужной даты:
       SELECT ItemId, InventLocationId, TurnQty
         FROM dbo.[Таблица_с_движениями] AS r
        WHERE r.RDate BETWEEN @DateStartMonth AND @Date
       ) AS one
 GROUP BY InventLocationId, ItemId
HAVING SUM(TurnQty) <> 0


Результаты:

--- Первый запрос:
(строк обработано: 182506)
Table '[таблица_с_остатками_на_даты_их_изменения]'. Scan count 5, logical reads 12705644, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 256, logical reads 31232, physical reads 3707, read-ahead reads 30045, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 89499 ms, elapsed time = 25709 ms.

-- Второй запрос:
(строк обработано: 182506)
Table '[Таблица_с_движениями]'. Scan count 1, logical reads 4174, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table '[Таблица_ежемесячных_срезов_остатков]'. Scan count 1, logical reads 1339, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 2527 ms, elapsed time = 3101 ms.

Как говорится, почувствуйте разницу. ;)
7 май 15, 16:33    [17613914]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
aleks2
Guest
1. Занафига вам остатки ВСЕХ товаров на всех складах?
2. Второй вариант вы можете реализовать на одной таблице, принудительно вставляя туды все остатки раз в месяц или раз в неделю.

SELECT r.ItemId, r.InventLocationId, r.RestQ
  FROM [таблица_с_остатками_на_даты_их_изменения] AS r
 right outer JOIN (
       SELECT InventLocationId, ItemId, max(RDate) AS MaxDate
         FROM [таблица_с_остатками_на_даты_их_изменения] AS r1
        WHERE r1.RDate <= @Date and r1.RDate > dateadd(month, -1, @Date)
        GROUP BY InventLocationId, ItemId
        ) AS MaxDates
    ON r.ItemId = MaxDates.ItemId AND r.RDate = MaxDates.MaxDate
   AND r.InventLocationId = MaxDates.InventLocationId
 WHERE r.RestQ <> 0
7 май 15, 17:51    [17614527]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
aleks2
1. Занафига вам остатки ВСЕХ товаров на всех складах?
2. Второй вариант вы можете реализовать на одной таблице, принудительно вставляя туды все остатки раз в месяц или раз в неделю.

SELECT r.ItemId, r.InventLocationId, r.RestQ
  FROM [таблица_с_остатками_на_даты_их_изменения] AS r
 right outer JOIN (
       SELECT InventLocationId, ItemId, max(RDate) AS MaxDate
         FROM [таблица_с_остатками_на_даты_их_изменения] AS r1
        WHERE r1.RDate <= @Date and r1.RDate > dateadd(month, -1, @Date)
        GROUP BY InventLocationId, ItemId
        ) AS MaxDates
    ON r.ItemId = MaxDates.ItemId AND r.RDate = MaxDates.MaxDate
   AND r.InventLocationId = MaxDates.InventLocationId
 WHERE r.RestQ <> 0


А вот теперь вам надо посчитать скорость продаж (среднюю штук в день на протяжении года). Как действовать будете с учётом того, что товар приходит и уходит?
7 май 15, 20:23    [17615097]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
aleks2
Guest
a_voronin
aleks2
1. Занафига вам остатки ВСЕХ товаров на всех складах?
2. Второй вариант вы можете реализовать на одной таблице, принудительно вставляя туды все остатки раз в месяц или раз в неделю.

SELECT r.ItemId, r.InventLocationId, r.RestQ
  FROM [таблица_с_остатками_на_даты_их_изменения] AS r
 right outer JOIN (
       SELECT InventLocationId, ItemId, max(RDate) AS MaxDate
         FROM [таблица_с_остатками_на_даты_их_изменения] AS r1
        WHERE r1.RDate <= @Date and r1.RDate > dateadd(month, -1, @Date)
        GROUP BY InventLocationId, ItemId
        ) AS MaxDates
    ON r.ItemId = MaxDates.ItemId AND r.RDate = MaxDates.MaxDate
   AND r.InventLocationId = MaxDates.InventLocationId
 WHERE r.RestQ <> 0


А вот теперь вам надо посчитать скорость продаж (среднюю штук в день на протяжении года). Как действовать будете с учётом того, что товар приходит и уходит?

Если вас сильно напрягают дополнительные записи в основной таблице - можете их пометить флажком и не использовать при загадочных расчетах.
8 май 15, 05:21    [17616009]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
гость 18
Guest
a_voronin
compresson
А если апгрейдить до 2008 Enterprise Edition и применить page compression то сколько будет размер таблицы 2?


Пробовал, плохая идея. Положит процессор.


Ну откуда у вас такая безапелляционность?
8 май 15, 08:23    [17616140]     Ответить | Цитировать Сообщить модератору
 Re: Подскажите оптимальный формат хранения данных таблицы  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
гость 18
a_voronin
пропущено...


Пробовал, плохая идея. Положит процессор.


Ну откуда у вас такая безапелляционность?


У меня остатков не 45971909, как упоминалось выше, у меня их 780 лямов. И я уже много способов попробовал.
8 май 15, 19:32    [17619823]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить