удобная структура базы для программы "Склад"
казалось что полная фигня не нужно даже думать.
Но... данная схема совсем не нравится. Да и все ориентировано на обычные магазины в сети. Хочется по другому.
Что есть : набор товаров, один поставщик, много клиентов (до 10), один маленький склад.
Что нужно минимум:
проводить инвентаризацию - подсчитывать количество товара на складе на конкретную дату, при этом хочется иметь "блочный" ввод. Лежит коробка с 10 штуками Х - вводим 10 штук, потом еще нашли Х -2 штуки, тоже вводим. Но в отчете будет 12 за инвентаризацию.
проводить прием товара - добавлять новое к уже имеющемуся, при этом дата годности будет уже другая. Приходит коробками по 10-20 штук.
проводить отбор товара - забирать товар по одному.
иметь отчеты по актуальному количеству и по предыдущим датам.
Основная проблема - как хранить товар-количество? Имея простые запросы и минимум таблиц.
Все делается чисто для себя, так что особых ограничений нет.
Как то все слишком по домашнему. Просто создаём сначало на бумаге одну таблицу и потом нормализует данные по правилам, пока не получим нормализованную базу данных
Ну или на крайняк просто рубим эту большую таблицу на мелкие, что бы исключить повторяемость данных и что бы получались не сильно сложные запросы
Просто создаём сначало на бумаге одну таблицу
так проблема то не в конкретных таблицах, а в принципе построения системы.
Вот нашел еще один - вся история в отдельных таблицах, а сумма в одной. Но как эту одну защитить от одновременного изменения? Не хочется еще специальный сервис делать.
Получается так:
Есть начальное состояние в отдельный момент времени.
Есть приход на момент времени
Есть расход на момент времени
Требуется оптимально получить текущее состояние в многопользовательской системе.
Похоже самое простое и надежное, все подсчитать начиная с даты последнего начального состояния. По приходу запроса, может еще кэш сделать.
это склад или магазин?
я бы сначала требования составил. просто в виде списоков.
кто потенциальные пользователи
типы транзакций
категории (просто перечень items, не знаю как обозвать) релевантные, там заказчики, поставщики, товары, группы товаров, ... в общем, все что вспомнится на данном этапе.
...
тогда только структуру базы попробовал бы набросать. но каждый, конечно, как ему удобнЕе поступает : )
это склад или магазин?
ни то и не другое. Я уже как то рассказывал - обеды на фирме. Но конкретная проблема ближе все же к складу.
Речь не идет о всей базе, там проблемы на каждом шаге. Решаю поэтому постепенно. Пользователи "сделаны" стандартным способом от Микрософта с ролями и прочей фигней.
Конкретную проблему "товары-количество" я вроде описал раньше. Хочется найти оптимальное решение. Что бы и запросы были "быстрыми" и работало надежно.
Самые быстрые запросы с одной таблицей: "продукт, количество", но ее нужно как-то синхронизировать с тремя другими: начальное состояние, приход, расход.
Самое надежное - это запросы на три предыдущих таблицы, но быстрыми они не будут. Хотя речь не идет о миллионах записей, может на тысячах и не стоит заморачиваться.
Вот пока и не знаю что лучше выбрать, первое, второе или что посередине.
Требуется оптимально получить текущее состояние в многопользовательской системе
Транзакции. Я не понимаю проблему. С базой данных проблема имхо не связана, в базе просто хранятся данные. Самое простое это не просчитывать, а менять состояние. Или добавлять новое состояние. После расхода уменьшать, после прихода увеличивать. А все приходы и расходы хранить в истории. Каждый раз просчитывать будет имхо долго.
Транзакции
не всегда хорошо. Хотелось бы без них.
https://habr.com/ru/post/86302/
Самое простое это не просчитывать, а менять состояние.
То бишь копируем начальное состояние, а после его меняем?
Хотелось бы без них.
-----
В многопользовательской без них не получится...
Кроме этого - у тебя пока еще "немножко не то"... когда учтешь все аспекты... ну хотя бы - цены + валюты - там будет под полтораста таблиц... а когда сделаешь почти идеально - добавится еще процентов 40... и она начнет тормозить уже из-за предельной нормализации...
Данные бывают критические и нет. Ну например товар. Его можно открыть на просмотр или на редактирование. При открытии на редактирование обьект блокируется. И пока блокировка не снята, его можно открыть только на просмотр. Таким образом для критических данных нет конкурирующего доступа. В статье это пессимистичный способ решения. Оптимистичный способ решения мне не нравится. Если данные не критичны, то кто последний сохранил, того и тапки. И нафиг какие то конфликты решать, их нельзя решить в принципе.
То бишь копируем начальное состояние, а после его меняем?
В таблицу "состояние" добавляем еще строчку. Можно и просчитывать, если приход и расход это пара сотен строчек. Иначе имхо слишком громоздкая выборка с последующим просчетом.
и она начнет тормозить уже из-за предельной нормализации...
Кстати как ни странно да. Мы опытным путем пытались найти компромисс между нормализацией и громоздкостью структуры базы данных. А потом вообще перешли на персистентный слой, работу с объектами, строили модель классов данных и разрешали персистентному слою самому строить базу данных.
А потом вообще перешли на...
-----
Не но теме, но...
Я тут упоминал часть моей работы по переходу на новую версию софта на фабрике передали одной конторке...
Ну оно у них не компилялось... потом вроде объяснил где код и что там с коннектионом - скомкомпилировалось... а дальше у них опять не получается.
Ну пока это у них не получается им дали другой кусок для адаптации.
Новая база - ПостгрееСкл, структура таблиц - другая, их существенно, почти вдвое, больше.
Возможность строить объекты и юзать ЕФ6 - есть.
Но ребятки пишут в стиле ФоксПро - команды - в файл, файл - в папочку. код загрузки и выгрузки команд - скрыт, логика обсчета - скрыта.
Папочка с командами - там никакой конвенции по поименованию команд нет - уже довольно объемная - шеф матюкается когда ищет нужное.
Мне подбрасывют "интересные" задачки - типа - выборка тут не правильная, не те данные показываются, надо определить какая из скл-ин юзается и ее поправить...
Самое смешное - адаптация скл-а ведется только в области синтаксиса.
Типа было для оракла - таблица@линкедсервер, будет для постгрее - схема.таблица...
Об том, что структура базы другая - вообще не думают.
В общем с Января - с перехода на новую версию - мне будет интересно... надо искать контракт на полгода...
Ах, да... поставщик отказался давать полную схему базы и/или реализованные объекты базы - ставит только комплекс как есть. Т.е. ни реляций, ни организации данных, ни логики обработки в наличии не будет...
когда учтешь все аспекты
их не так уж и много, но хватает. Но я делаю постепенно, что бы можно было начать пользовать побыстрее. Тогда и новые хотелки появятся.
ну хотя бы - цены + валюты
Тут проще. Цена и валюта одна на продукт и все в евриках, но все равно сделаю чтобы цену можно было менять по дате.
В многопользовательской без них не получится...
ну у меня не будет даже и пару десятков пользователей. Есть только одно место когда народ валит обед брать. И усложнять дата layer не очень хочется.
С другой стороны работа как бы учебная, можно поиграться.
В таблицу "состояние" добавляем еще строчку
одной строчкой не обойдешься. Нужны данные по каждому продукту. И еще есть конечная дата использования продукта, но это следующий шаг.
Изменять глобальный объект - это проблема с блокировкой и где то забыл его изменить или не в той последовательности. Поэтому не сильно хочется, но зато быстрее уже не будет.
Мы опытным путем пытались найти компромисс между нормализацией и громоздкостью структуры базы данных.
А теоретически и не получится, пока не попробуешь. Некоторые объекты ясно, что нужно в блоб закидывать, а с другими, фиг знает как выборку делать в этом случае. Приходилось извращаться.
одной строчкой не обойдешься.
-----
Если спроектировано правильно - обойдешься именно добавлением одной строки данных в таблицу.
Это если логика - в коде. Хочешь вынести - не забудь обновить Воркфлов. Я тут днями свеженький смотрел - выглядит - прилично... правда у меня для Коре ничего не инсталлено....
Если спроектировано правильно - обойдешься именно добавлением одной строки данных в таблицу.
очень хочется глянуть на правильное проектирование, когда сведения о 20 товарах можно добавить одной строкой.
Хотя у тебя вроде и сотни делают без проблем
Я тут днями свеженький смотрел
Это EF что ли? Вроде последний стоит. Пришлось правда откатить Коре на 3.0 с 3.1 - сервер еще не поддерживает.
Database first правда так и не удалось запустить или найти хоть какой то ER designer для EF и Core 3.
когда сведения о 20 товарах можно добавить одной строкой.
Нет, конечно. Каждый товар учитывается отдельно. Одна строчка про товар. Приход и расход в истории тоже потоварно
Это EF что ли?
-----
Причем тут ЕФ?
Воркфлов - отдельно и вне аппа описывает сценарий действий... можно поменять все, не меняя кода приложения...
Интеграция получается довольно удобная. Правда как надо описывать мне не нравится...
И пока не видел, чтобы обработку описаний выполнили на самом Воркфлове...
Database first правда так и не удалось запустить
-----
У меня - работает.
Правда - довольно медленно... если правильно помню - минут 10-15 для ~1400 таблиц... и без реляций - не интересно.
Воркфлов - отдельно и вне аппа описывает сценарий действий.
не попадалось еще - это что ли?
https://social.technet.microsoft.com/wiki/contents/article...
У меня - работает.... и без реляций
Ну больше чем ничего, но кому это надо? Или только посмотреть?
А что именно у тебя работает? Entity Framework Visual Editor?
так приятно тема была сформулирована и первый пост казался многообещающим, но я очень скоро затупил, как только начался сплошной теоретизм. снова такое впечатление, что все что-то знают такое, о чем я не догадываюсь. вы что - еще и в привате перестукиваетесь? : )
вы что - еще и в привате перестукиваетесь?
неа у нас телепатические сеансы
зато хоть проблему удалось сформулировать , а то раньше вообще все разбегалось.
А какие будут еще предложения?
-----
Ну можно попробовать в подготовленные места... не Ексел же...
А что именно у тебя работает?
-----
EF6 s Database First po PostgreeSQL.
Ну больше чем ничего, но кому это надо? Или только посмотреть?
-----
Ну так большего сделать не могу - нет полной схемы базы.
Либо надо руками дорисовывать и не факт что возможно, либо описывать руками...
На текущих объемах - 3-5 лет работы...
Entity Framework Visual Editor?
-----
Не помню. Добился генерации базовых объектов - дальше текучка сожрала...
Цена и валюта одна на продукт и все в евриках
-----
Эээ... Тут как раз попалось под руку...
Цены - в еврах. Евров этих насчиталось... ТРИ штуки - EUR, EURA, EURX...
Тебе с бухами стоит проконсультироваться....
Ну можно попробовать в подготовленные места...
Хм, Сэр что то вы сильно недоговариваете. Это в заранее подготовленные 20 таблиц?
https://github.com/aelassas/Wexflow
Надо будет еще почитать, от МС не проняло. Никак нужность не дойдет.
А что именно у тебя работает?
В пункте 3 нет "ADO.NET Entity Data Model"
https://docs.microsoft.com/en-us/ef/ef6/modeling/designer/...
Тебе с бухами стоит проконсультироваться...
Так говорю же- проект можно сказать частный. Все сейчас делается силами работников. Девочка заказывает еду и собирает деньги на свой личный счет, остальное на бумажках
Еда заказывается у одной приличной немецкой фирмы. Так что с этой стороны проблем никаких.
В пункте 3 нет "ADO.NET Entity Data Model"
-----
Есть, но не пользовался...
Вот решу что делать с новым железом - буду думать что и как ставить/юзат'...
Hi!
В 1C (РФ) так и ведется учет и расчет остатков: есть текущее начальное состояние (какой то момент времени и значение ресурса в нем) и остаток есть сумма Расхода-Прихода. Начальное состояние периодически сдвигается за текущим временем (ранее было каждый месяц, отдельный перерасчет Таблиц (Регистров), в новых версиях автоматом как то. Плюс есть понятие Граница Последовательности, которая и определяет актуальное Начальное состояние. Sorry, если поздно.
Спасибо, конечно, но что то ничего не понял
Хотя уже основа работает и меняться кардинально ничего не будет. При этом расчетный период у меня может быть любым. Хошь вначале неделя, а потом хошь пару месяцев.