Deutsch
Germany.ruФорумы → Архив Досок→ Программирование

удобная структура базы для программы "Склад"

1671  1 2 все
AlexNek патриот16.11.19 13:31
AlexNek
16.11.19 13:31 

казалось что полная фигня не нужно даже думать.


Но... данная схема совсем не нравится. Да и все ориентировано на обычные магазины в сети. Хочется по другому.

Что есть : набор товаров, один поставщик, много клиентов (до 10), один маленький склад.

Что нужно минимум:

проводить инвентаризацию - подсчитывать количество товара на складе на конкретную дату, при этом хочется иметь "блочный" ввод. Лежит коробка с 10 штуками Х - вводим 10 штук, потом еще нашли Х -2 штуки, тоже вводим. Но в отчете будет 12 за инвентаризацию.

проводить прием товара - добавлять новое к уже имеющемуся, при этом дата годности будет уже другая. Приходит коробками по 10-20 штук.

проводить отбор товара - забирать товар по одному.

иметь отчеты по актуальному количеству и по предыдущим датам.

Основная проблема - как хранить товар-количество? Имея простые запросы и минимум таблиц.

Все делается чисто для себя, так что особых ограничений нет.


#1 
koder патриот16.11.19 14:10
koder
NEW 16.11.19 14:10 
в ответ AlexNek 16.11.19 13:31, Последний раз изменено 16.11.19 14:12 (koder)

Как то все слишком по домашнему. Просто создаём сначало на бумаге одну таблицу и потом нормализует данные по правилам, пока не получим нормализованную базу данных


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

#2 
AlexNek патриот16.11.19 14:19
AlexNek
NEW 16.11.19 14:19 
в ответ koder 16.11.19 14:10
Просто создаём сначало на бумаге одну таблицу

так проблема то не в конкретных таблицах, а в принципе построения системы.


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



#3 
AlexNek патриот16.11.19 16:33
AlexNek
NEW 16.11.19 16:33 
в ответ AlexNek 16.11.19 14:19

Получается так:

Есть начальное состояние в отдельный момент времени.

Есть приход на момент времени

Есть расход на момент времени

Требуется оптимально получить текущее состояние в многопользовательской системе.

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

#4 
  moose старожил16.11.19 16:53
NEW 16.11.19 16:53 
в ответ AlexNek 16.11.19 13:31

это склад или магазин?

я бы сначала требования составил. просто в виде списоков.

кто потенциальные пользователи

типы транзакций

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

...

тогда только структуру базы попробовал бы набросать. но каждый, конечно, как ему удобнЕе поступает : )

#5 
AlexNek патриот16.11.19 17:27
AlexNek
NEW 16.11.19 17:27 
в ответ moose 16.11.19 16:53
это склад или магазин?

ни то и не другое. Я уже как то рассказывал - обеды на фирме. Но конкретная проблема ближе все же к складу.

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

Конкретную проблему "товары-количество" я вроде описал раньше. Хочется найти оптимальное решение. Что бы и запросы были "быстрыми" и работало надежно.

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

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

Вот пока и не знаю что лучше выбрать, первое, второе или что посередине.

#6 
koder патриот16.11.19 19:49
koder
NEW 16.11.19 19:49 
в ответ AlexNek 16.11.19 16:33
Требуется оптимально получить текущее состояние в многопользовательской системе


Транзакции. Я не понимаю проблему. С базой данных проблема имхо не связана, в базе просто хранятся данные. Самое простое это не просчитывать, а менять состояние. Или добавлять новое состояние. После расхода уменьшать, после прихода увеличивать. А все приходы и расходы хранить в истории. Каждый раз просчитывать будет имхо долго.

#7 
AlexNek патриот16.11.19 20:12
AlexNek
NEW 16.11.19 20:12 
в ответ koder 16.11.19 19:49
Транзакции

не всегда хорошо. Хотелось бы без них.

https://habr.com/ru/post/86302/


Самое простое это не просчитывать, а менять состояние.

То бишь копируем начальное состояние, а после его меняем?



#8 
Murr патриот17.11.19 02:36
Murr
NEW 17.11.19 02:36 
в ответ AlexNek 16.11.19 20:12

Хотелось бы без них.

-----

В многопользовательской без них не получится...


Кроме этого - у тебя пока еще "немножко не то"... когда учтешь все аспекты... ну хотя бы - цены + валюты - там будет под полтораста таблиц... а когда сделаешь почти идеально - добавится еще процентов 40... и она начнет тормозить уже из-за предельной нормализации...

#9 
koder патриот17.11.19 06:36
koder
NEW 17.11.19 06:36 
в ответ AlexNek 16.11.19 20:12

Данные бывают критические и нет. Ну например товар. Его можно открыть на просмотр или на редактирование. При открытии на редактирование обьект блокируется. И пока блокировка не снята, его можно открыть только на просмотр. Таким образом для критических данных нет конкурирующего доступа. В статье это пессимистичный способ решения. Оптимистичный способ решения мне не нравится. Если данные не критичны, то кто последний сохранил, того и тапки. И нафиг какие то конфликты решать, их нельзя решить в принципе.

#10 
koder патриот17.11.19 06:40
koder
NEW 17.11.19 06:40 
в ответ AlexNek 16.11.19 20:12
То бишь копируем начальное состояние, а после его меняем?

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

#11 
koder патриот17.11.19 06:45
koder
NEW 17.11.19 06:45 
в ответ Murr 17.11.19 02:36
и она начнет тормозить уже из-за предельной нормализации...

Кстати как ни странно да. Мы опытным путем пытались найти компромисс между нормализацией и громоздкостью структуры базы данных. А потом вообще перешли на персистентный слой, работу с объектами, строили модель классов данных и разрешали персистентному слою самому строить базу данных.

#12 
Murr патриот17.11.19 09:36
Murr
NEW 17.11.19 09:36 
в ответ koder 17.11.19 06:45

А потом вообще перешли на...

-----

Не но теме, но...

Я тут упоминал часть моей работы по переходу на новую версию софта на фабрике передали одной конторке...

Ну оно у них не компилялось... потом вроде объяснил где код и что там с коннектионом - скомкомпилировалось... а дальше у них опять не получается.

Ну пока это у них не получается им дали другой кусок для адаптации.

Новая база - ПостгрееСкл, структура таблиц - другая, их существенно, почти вдвое, больше.

Возможность строить объекты и юзать ЕФ6 - есть.

Но ребятки пишут в стиле ФоксПро - команды - в файл, файл - в папочку. код загрузки и выгрузки команд - скрыт, логика обсчета - скрыта.

Папочка с командами - там никакой конвенции по поименованию команд нет - уже довольно объемная - шеф матюкается когда ищет нужное.

Мне подбрасывют "интересные" задачки - типа - выборка тут не правильная, не те данные показываются, надо определить какая из скл-ин юзается и ее поправить...

Самое смешное - адаптация скл-а ведется только в области синтаксиса.

Типа было для оракла - таблица@линкедсервер, будет для постгрее - схема.таблица...

Об том, что структура базы другая - вообще не думают.

В общем с Января - с перехода на новую версию - мне будет интересно... надо искать контракт на полгода...


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

#13 
AlexNek патриот17.11.19 12:07
AlexNek
NEW 17.11.19 12:07 
в ответ Murr 17.11.19 02:36
когда учтешь все аспекты

их не так уж и много, но хватает. Но я делаю постепенно, что бы можно было начать пользовать побыстрее. Тогда и новые хотелки появятся.


ну хотя бы - цены + валюты

Тут проще. Цена и валюта одна на продукт и все в евриках, но все равно сделаю чтобы цену можно было менять по дате.


В многопользовательской без них не получится...

ну у меня не будет даже и пару десятков пользователей. Есть только одно место когда народ валит обед брать. И усложнять дата layer не очень хочется.

С другой стороны работа как бы учебная, можно поиграться.

#14 
AlexNek патриот17.11.19 12:15
AlexNek
NEW 17.11.19 12:15 
в ответ koder 17.11.19 06:40
В таблицу "состояние" добавляем еще строчку

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

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

#15 
AlexNek патриот17.11.19 12:24
AlexNek
NEW 17.11.19 12:24 
в ответ koder 17.11.19 06:45
Мы опытным путем пытались найти компромисс между нормализацией и громоздкостью структуры базы данных.

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

#16 
Murr патриот17.11.19 13:10
Murr
NEW 17.11.19 13:10 
в ответ AlexNek 17.11.19 12:15

одной строчкой не обойдешься.

-----

Если спроектировано правильно - обойдешься именно добавлением одной строки данных в таблицу.

Это если логика - в коде. Хочешь вынести - не забудь обновить Воркфлов. Я тут днями свеженький смотрел - выглядит - прилично... правда у меня для Коре ничего не инсталлено....

#17 
AlexNek патриот17.11.19 13:24
AlexNek
NEW 17.11.19 13:24 
в ответ Murr 17.11.19 13:10
Если спроектировано правильно - обойдешься именно добавлением одной строки данных в таблицу.

очень хочется глянуть на правильное проектирование, когда сведения о 20 товарах можно добавить одной строкой. смущ

Хотя у тебя вроде и сотни делают без проблем спок

#18 
AlexNek патриот17.11.19 13:36
AlexNek
NEW 17.11.19 13:36 
в ответ Murr 17.11.19 13:10
Я тут днями свеженький смотрел

Это EF что ли? Вроде последний стоит. Пришлось правда откатить Коре на 3.0 с 3.1 - сервер еще не поддерживает.

Database first правда так и не удалось запустить или найти хоть какой то ER designer для EF и Core 3.

#19 
koder патриот17.11.19 15:28
koder
NEW 17.11.19 15:28 
в ответ AlexNek 17.11.19 13:24
когда сведения о 20 товарах можно добавить одной строкой.


Нет, конечно. Каждый товар учитывается отдельно. Одна строчка про товар. Приход и расход в истории тоже потоварно


#20 
1 2 все