Посоветуйте что лучше ?

LSash

Есть таблица где хранятся наименования товара.Надо к этим наименованиям привязать кол-во этого товара на складах.Т.к. Складов несколько, и периодически появляются новые, возникла проблема как лучше реализовать хранение.Кол-во наименований около 200000Складов пока 15Пока вижу два пути1. Хранить в одной таблице кол-во + указание к какому складу оно относится. Но тогда получается что таблица будет огромного размера, а при добавлении нового склада будет расти еще больше2. Создавать для каждого склада отдельную таблицу, но тогда придется использовать в хп динамические запросы, что я тут вычитал тоже не способствует повышению производительности.Может есть третий вариант о котором я не знаю ?
18 ответов

LSash

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


LSash

2LSashТолько "1"Для такого мизерного количества создавать себе геморрой??? Да ещё и работать будет медленнее....Таблица к-ва будет хоть и с большим к-вом строк, но узкая (3 числа)


LSash

2LSashТолько "1"Для такого мизерного количества создавать себе геморрой???
У нас наверно разные представления о больших объемах. Хотя если для MS SQL это мизер, то это есть очень хорошо :)Если не секрет, какие объемы SQL сервер считает не мизерными ?


LSash

Кол-во наименований около 200000Складов пока 15Всего 200000? Или у каждого склада 200000 ?


LSash

Всего 200000, прирост не большой максимум 100 позиций в месяц, обычно меньше


LSash

Стандартная схема: 3 табличкисправочник товарасправочник складаПремещения товара.


LSash

2LSashДаже если для каждого наименования прописывать к-во на складе, в т.ч. нулевое, получится 3 млн. записей. ПК в таблице - склад и товар. Типичные выборки - мгновенные. Сравните это с необходимостью делать динамические запросы (в т.ч. и для секционированных представлений - САМ Glory писал, что планы неэффективны при использовании переменных в критериях).
Если не секрет, какие объемы SQL сервер считает не мизерными ?
Не мизерные - ну сотня милионов строк, десятки гигов базы. Проблем особых не бывает, нужны внятные разработчики, админы, ну и железо не отстойное. Но в принципе - ничего особенно страшного.А большие... Сам с такими не работал. Говорят (по слухам), это террабайтные базы и миллиарды строк. Возможно, там большие проблемы и не так всё просто. Но я об этом не знаю.Ну и вообще, всё относительно - смотря что делать с этими данными. Повторю - для данной схемы проблем не будет, даже если записей будет больше.ЗЫ. Рекомендую общее к-во (наверняка понадобится) хранить в товарах, а не считать каждый раз суммируя по складам.


LSash

2svadnсправочник складаВ справочнике склада информация по всем складам ?


LSash

Да, т.е. в твоем случае 15 строк


LSash

2alexeyvg Рекомендую общее к-во (наверняка понадобится) хранить в товарах, а не считать каждый раз суммируя по складам.Ага, так и делаю :)Всем спасибо.


LSash

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


LSash

2svadn
Общее кол-во товара, лучше вычислять по таблице перемещений. Тогда можно будет видеть кол-во в разрезе складов, и на любой момент времени.
Т.е. хранение общего к-ва в таблице товаров не позволит при необходимости по таблице перемещений видеть кол-во в разрезе складов, и на любой момент времени? :-)По-моему, использование только таблицы перемещений оправдано только в том случае, когда никогда не требуется знать текущее к-во. А такие задачи нечасто встречаются.


LSash

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


LSash

Полезно как-то хранить зарезервированное кол-во в разрезе склада.Так что нужно минимум ещё одно поле.Хранить резервы в отдельной таблице может оказаться нерациональным. ИМХОСхема: ТоварНо - СкладНо - Колво - РезервКолвоПожалуй самая приемлимая...хотя нельзя получить наличие на нужную дату :(Получать наличие из перемещений будет вааще медленно..там же многие миллионы строк будут и полей поболее, но для наличия на датуэто пожалуй единственный выход... :(


LSash

Текущее значение кол-ва, если оно разбито по трем складам мало кому интересно. В складских модулях важнее кол-во в разрезе складов. Вот сальдо поставщика действительно нужно хранить в карточке поставщика, а не вычислять. Хотя специфика всякая бывает :)
Конечно, задачи разные у всех. По складам самый частый запрос - показать текущее к-во (или несколько разных количеств - имеющееся свободное к продаже, имеющееся проданное, имеющееся рарезервированное и т.д.) Чтений всегда будет больше, чем модификаций. Так зачам вычислять при каждом чтении по таблице перемещений товаров за последние 100 лет? Не легче-ли считать одно поле по ПК? Собственно, это вопрос такой-же, как и сальдо - вычислять по документам при чтении или хранить, вычисляя при изменении.Общее к-во по всем складам - вот это действительно нечасто нужно (зависит от задачи) - можно этого и не делать.
Полезно как-то хранить зарезервированное кол-во в разрезе склада.Так что нужно минимум ещё одно поле.
Ну возможны и ещё много полей. Человек ещё начинает :-)
Получать наличие из перемещений будет вааще медленно... там же многие миллионы строк будут и полей поболее, но для наличия на датуэто пожалуй единственный выход... :(
Пучему единственнй выход? Можно сделать "суммарную" таблицу перемещений по датам(без времени): ПК - дата, склад и товар. Будет меньше записей и легче запросы (без агрегатов). Причём я в таких случаях дату храню как челое число (сегодня 20040610)


LSash

Я предложил стандартный структуру: справочник+перемещения. Так работают все складские системы, от 1с до oracle и sap, естественно в этих системах не 3 таблички и даже не 30, но идеология та же самая.А дополнительные таблицы для того и используются, чтобы ускорять тормозящие запросы и расширять функционал системы.


LSash

>> ... "суммарную" таблицу перемещений...Это наверно речь про накопительный итог ?Действительно такое решение есть и работает очень(!) быстро...(сеть из 20 магазинов, суммарные продажи за год потоварно(!) считает за пару десятков сек !!!)Но при этом немного усложнены изменения задним числом, да и готовятсятакие итоги медленно.Короче... Вариантов много, каждый хорош по своему. Осталось только выбрать.. :)


LSash

2LSV Наверное, не совсем про накопительный итог... Хотя может быть...На мой взгляд, в данном случае речь идёт именно о складе, и в этих таблицах я говорил о состоянии склада (к-во на складе) - текущем и на дату.Для движений можно туда писать и к-во прихода/ухода в день.А продажи нужно считать по заказам. Соответственно, для быстрых отчётов можно хранить суммарные продажи в день. Т.е. не надо делать "неделимую" систему склад-продажи - это две подсистемы, каждая со своим набором данных.Насчёт медленности и сложности - непонятно. Пришёл товар - апдейт таблицы состояния склада - поле текущего к-ва на соотв. дату + приход (и неважно, задним числом пришёл или передним). Что тут медленного или сложного?