удобная структура базы для программы "Склад"
казалось что полная фигня не нужно даже думать.
Но... данная схема совсем не нравится. Да и все ориентировано на обычные магазины в сети. Хочется по другому.
Что есть : набор товаров, один поставщик, много клиентов (до 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 товарах можно добавить одной строкой.
Нет, конечно. Каждый товар учитывается отдельно. Одна строчка про товар. Приход и расход в истории тоже потоварно