SQL

Вопросы по проектированию базы данных для небольшого склада.

Есть небольшой склад с комплектующими и инструментом.
Комплектующие могут поступать новые от поставщиков, так и б\у из офиса (например при замене монитора, системного блока, блока питания и т. д.).
Так же железка (и старая и новая) может переместиться со склада в офис.
И новые комплектующие могут быть отгружены заказчику.
Еще есть инструмент (отвертки, пассатижи...) и расходники (коннекторы, припой...), котоыре могут быть проданы или переданы\установлены в офисе.

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

Отсюда возникают вопросы:
1) Наверное нужны две таблицы с типами поступлений и отгрузок товара (из офиса\в офис, приход по ТТН\возврат по гарантии, отгрузка клиенту\возврат по гарантии)?
2) Нужны ведь и собственно две таблицы с поступлениями и отгрузками, где полями будут ID движения, тип движения из таблиц пункта 1, ID железки\инструмента\расходника, и количество (ничего не забыл?)?

И самый главный вопрос это таблица (ы) для самих ТМЦ. Как спроектировать их структуру?
Можно ли запихнуть все в одну таблицу или под каждую сущность заводить отдельную таблицу?
По сути мне важно только где чего сколько СЕЙЧАС находится и в каком оно состоянии (новое не новое) и не важно сколько было мониторов или кабелей питания на какую-то дату.
Характеристики комплектующих тоже особо не интересуют, все будет отражено в названии, например на складе есть оперативная память PSD32G160081 DDR3 2GB 1600MHz, новая, в количестве 4 шт.
И две планки такой же, но не новой на складе.
И шесть планок новых ушло в офис.
И четыре не новых ушло туда же.
И как всё это хранить?
Буду весьма признателен, если что-то посоветуете.
ЕА
Евгений Агеев
2 162
Чтобы не путаться в терминологии, пролистайте статью вики.

Вы пытаетесь сразу нарисовать физическую модель БД. Это типичная ошибка начинающего.

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

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

Применительно к вашей задаче:
В концептуальной модели у вас будет 2 таблицы: ТМЦ и история их движения. После нормализации появятся служебные таблицы контрагентов и типов ТМЦ.
При переходе к реализации часть истории (появление и текущее состояние) будет добавлено в таблицу ТМЦ. Это будет сделано потому, что наиболее частые запросы будут затрагивать именно эти поля, нам же нужно знать, где сейчас находится конкретнаяТМЦ? Возможно добавятся таблицы агрегации ТПЦ по каждому контрагенту, ведь запросы "сколько памяти по 2 Гб у меня в наличии? " тоже достаточно частые.
АР
Алексей Разуваев
11 112
Лучший ответ
Евгений Агеев Благодарю за потраченное время. Очень ценю, что проходя мимо, не смогли пройти мимо.

Статью почитал, спасибо, примерно так всегда и старался делать.
Сейчас пожалуй начну заново, на бумаге опишу всё, что должно быть учтено, и какие выборки будут нужны в процессе работы.
Сидел долго думал, как прокомментировать Ваш ответ, написал портянку текста о том, как будет тяжко всё привести к 1НФ, какой пухлый будет номенклатурный справочник, и как придумывание классификатора оттянет по времени окончание разработки приложения.
И прикинув сколько видов ТМЦ по факту нужно учитывать, понял, что не особо то развесистая получится БД.
До денормализации для ускорения запросов, я думаю дело, не дойдет. Пользоваться программой буду я один, и скорее всего в качестве базы будет использована SQLite.
Евгений Агеев Записей будет не сильно много, да и из нормальной формы получить ненормальную будет проще чем наоборот.
Вобщем все советы ценные, все их услышал и учту.
Еще раз большое спасибо и дай бог здоровья.
Самый простой способ воспользовать Excel. Только Файлом должен ведать один какой-то человек на Локальном компьютере. Если Выложить в Доступ, то Файл могут Открыть несколько человек. Один внесёт Изменения, а другой будет что-то другое вносить. В итоге останется то, что было Сохранено последним. Получится конфликт. В Excel есть ещё одна проблема. Необходимо сводить данные на один день, неделю, месяц. Т. е. нельзя всё впихивать в один Файл. Файл может Сломаться. Тама есть физический предел. Это как нельзя на FAT Записать больше 4 ГБ Файл, т. к. есть физический предел. Тама такая же проблема! На ходу, пока делаешь, всё будет впечатываться, а вот, вроде бы, Сохранишь, Закроешь, и попытаешься (сразу же или спустя некоторое время) Открыть, и Файл уже разодран (тама какая-то каша творится).
 
Есть, вроде бы, 1S (1С-Бухгалтерия), но там нужен уже Поднятый Сервер. Программа лицензионная. Оч. дорогостоящая. Пираток нету, вроде бы.
 
Есть такой вариант, сделать что-то типа html-Страниц с возможностью Редактирования Таблиц. Видел только со стороны. Как у них осуществляется запрет на Доступ нескольких человек одновременно к Редактированию Полей Таблиц, — не знаю. Наверное что-то есть. Точно не знаю, но либо PHP надо знать, либо это делается на Шаблонах Форумов?
 
Есть ещё какие-то способы, допустим работать с БД на MS-Access (если правильно написал название Программы).
 
На худой конец, можно в Word или AutoCAD всё свести. Раньше люди и вовсе в Блокноте всё Сохраняли. Брали и оформляли под определённый Операционной Системой Шрифт. Получалось вполне себе красиво!
 
В общем, было бы желание, а остальное приложится. Вот мои самые-пресамые простейшие варианты (набросал чё-попало от винта в Блокнот, Сконвертировал в Excel, Суммировал и вновь Вставил в Блокнот) — см. фото внизу. Десять-пятнадцать минут потратил. Делается всё на ходу быстро и легко! Конечно же, если числа настоящие, то там нужны внимательность и аккуратность, а то получится какая-нибудь хрень! :D ¦D #D XD
 
14:14 21.03.2016
Оleg Oleg
Оleg Oleg
7 216
Евгений Агеев Благодарю за столь развернутый ответ, но офисные продукты майкрософт не подходят.
Таблица итак хранится в таблицах гуглдокс, и именно от этого варианта нужно уйти. Можно это написать на PHP (и на практически любом другом ЯП, мой выбор пал на java), но для того чтобы писать логику программы, нужна база данных, в которой будет храниться информация о сущностях, перечисленных в вопросе.
Именно структура базы данных меня и интересует.
В любом случае благодарю за советы.
Вот, зайдите на сайт там вам обязательно помогут !
http://проектсклада. рф
Вадим Уваров
Вадим Уваров
116
Ugu
Вит@лий .
Вит@лий .
101

Похожие вопросы