Оцените сложность поставленной задачи

[WMix]

С каждым высказыванием ты больше и больше подтверждаешь правдивость предположения о твоем уровне

 

[Yoskaldyr]

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

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

 

[флоппик]

@Yoskaldyr, да сто за двести, щас окажется, что там все уже считается в какие-нибудь materialized view, много источников данных, и поэтому постановку "никаких новых таблиц не надо создавать" пришлось озвучить. Почитав предыдущие темы этого автора, ты увидишь что у него проблемы с восприятием своего уровня разработки.

 

[Alex7965]

Да нет там ничего, елы-палы. Насчет сложного sl запроса....Во-первых у нас это крайне неприветствуется, то бишь написание чтот-о низкоуровневое. У меня уже были попытки, так там сразу тимлид руками замахивал...типа работай только с объектами. Во-вторых, запрос который предложил товарищ, крайне, как бы это сказать, "дорогостоящий", будет очень много вычислений и прочего. Подобную задачу можно решить подобным образом, но это очень не эффективно раз и ее мне не дадут решить подобным образом два. Все, побежал я на работу, всем спасибо за помощь и советы )

 

[Yoskaldyr]

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

 

[Yoskaldyr]

Хотя скорее всего там вся контора типа конторы @scorpion-ds

 

[WMix]

как бы это сказать, "дорогостоящий"

не высасывай из пальца проблемы на 10 складов и 1000 товаров по 5000 накладных на товар лет так на 10 хватит а там и инвентаризация поспеет
у нас табличка с более 50 Мио записей и join на 12 таблиц. запрос отрабатывает менее секунды при правильном индексе.

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

нет задачи показать все и сразу, будет всегда интересовать конкретный товар после where отсечется 99,9% информации (1 товар из 1000)

 

[Yoskaldyr]

@WMix, Быть может, но скорее будет показать список товаров на складе с остатками + пагинация + 100500 фильтров.
Вот тут как раз фулсканы и прочая веселуха, потому что как раз это значительно чаще встречается при складском учете.

И как раз это и будет прикладывать базу. И никакие индексы не помогут, т.к. складов часто не сильно много и как результат фильтр по складу сильно не уменьшит выборку, а может вообще не уменьшить, а оптимизатор запросит фулскан.

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

Одним словом что-бы дать точный ответ надо знать все нюансы конкретной задачи а не просто общие фразы как лучше сделать оторвано от реальной задачи

 

[Yoskaldyr]

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

P.S. Вот @WMix похоже не знает про минусы или просто не наступал на грабли этих минусов или просто пофиг ))). Может повезло и конкретные данные хорошо ложатся на эту схему или в условиях конкретного приложения пофиг на тормоза.

 

[ivanov77]

нет задачи показать все и сразу, будет всегда интересовать конкретный товар после where отсечется 99,9% информации (1 товар из 1000)

задачу в первой теме он описал как "сотрудник запрашивает информацию по остаткам на том или ином складе" и "вывести инф-цию какие товары и какое количество есть на каждом конкретном складе"

 

[ivanov77]

Он меня вогнал в ступор, когда сказал, что решение использовать что-то наподобие однаэсовских регистров накопления будут нарушать 3 нормальную форму

Добавление таблицы с остатками он назвал нарушением 3-й формы?
Очень подозрительно.
Может он так проверяет тебя, проглотишь ли чушь...
Или он сам склонен такое нести, очень неприятно тогда, что он такими способами запутывает.
Очевидно же что 3-я форма не о том.

Если им такого решения раньше хватало то в чем проблема делать по 4 запроса и считать остатки на php? Раз так просят.

 

[WMix]

задачу в первой теме он описал как "сотрудник запрашивает информацию по остаткам на том или ином складе" и "вывести инф-цию какие товары и какое количество есть на каждом конкретном складе"

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