Таблица мест.
Таблица движений.
Таблица оборудования.
Приход, перемещение и списание - одно и тоже движение. Приход - из условного внешнего мира на конкретное место, перемещение - с одного места на другое, списание - из места в внешний мир.
Таблица калибровок.

Может/должен быть вменяемый классификатор типов и видов оборудования, группировка мест (предприятие-цех-участок-помещение).

авторТаблицы: тОбьект:имя; тМесто:имя,id_тОбьект; тТип:имя; тПрибор:имя,id_тТип; тДвижение:имя

а основную таблицу одну делать?
1. id_тДвижение,id_тМесто,id_тПрибор,количество,дата,серийныйномер,описание

или несколько, тогда тДвижение не нужна

1. id_тПрибор,количество,дата и наверно id_тМесто(куда со склада ушло оборудование)
2. id_тМесто,id_тПрибор,дата,серийныйномер,описание(в описание все изменения с прибором)

Что ж так слабо-то ?

Таблица мест (ПК идМеста, НазваниеМеста, ...)
Таблица оборудования (ПК идОборудования, НазваниеОборудования, СерийныйНомер, ...)
Таблица движений (ПК идДвижения, ФК идМестаОткуда, ФК идМестаКуда, ФК идОборудования, ДатаПеремещения, ...)
Таблица регламентных работ (ПК идРаботы, ФК идОборудования, ДатаРаботы, ...)

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

Прием в эксплуатацию - Движение идМестаОткуда=NULL, идМестаКуда=...
Списание - Движение идМестаОткуда=..., идМестаКуда=NULL

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

Как-то неправильно на этом ресурсе говорить "набросайте готовую структуру для меня".

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

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

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

авторМне эта идея очень понравилась и разве предпоследняя схема не то что вы рекомендовали, только как реализовать учет кнопок и индикаторов? Создать какую то отдельную таблицу учета?
Сравните свою схему и описание:
авторТаблица движений (ПК идДвижения, ФК идМестаОткуда, ФК идМестаКуда, ФК идОборудования, ДатаПеремещения, ...)

Прием в эксплуатацию - Движение идМестаОткуда=NULL, идМестаКуда=...
Списание - Движение идМестаОткуда=..., идМестаКуда=NULL

С вашей схемой ничего общего. Вы вообще понимаете что вам пишут в вашем топике ?

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

В таблицу движений можно добавить поле Кол-во, в таблицу оборудования - признак, учитывается ли данное оборудование как индивидуальная единица или партиями с заданным кол-вом одинаковых экземпляров. Этот флажок должен будет играть на формах ввода, с точки зрения расчета остатков по местам установки все будет считаться правильно (с умножением на 1 или на реальное кол-во штук при движении). Т.е. закупили 20, 3 поставили в одно место, 12 - в другое, 5 штук еще осталось в запасе.


автор1. Привезли нам оборудование: приборы с серийными номерами, кнопки, выключатели,индикаторы - записать в приход(марку,количество, серийный номер если есть,дату прихода).

2. Поставил оборудование в цех: записать куда установлено, если прибор то серийный номер, если кнопки и выключатели то количество, дату установки.

3. Внесли изменения в прибор: записать где он установлен, какой именно прибор(серийный номер), дата изменения, что изменили.

4. Сломалось оборудование: списать по маркировке и серийному номеру(приборы) или по маркировке и количеству(кнопки),дата списания


Все реализуется через таблицу движений. Выше я уже объяснял как. С добавлением по количество решается учет массовых однотипных кнопок и пр. мелочевки.

2: серийный номер меняется при установке ??? Серийный номер заносится при поступлении прибора и больше не меняется. Во всех таблицах используется НЕ СЕРЙНЫЙ номер, а суррогатный пк - автосчетчик.

Текущая картина, что где установлено и в каком состоянии, решается запросами.


Кто поставил ? Владельцы бизнеса ? Купить программу им слабо ? Потратиться на фриланс не желают ? Вы взялись, это входит в ваши обязанности/компетенции ?

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

Я смотрю на те схемы, которые выложен в данной ветке. В последней из них в таблице Движение написано:

Имя
идЗдание
датаПеремещения
идПрибор
Количество

Ходить куда-то по ссылкам не могу. Если хотите комментариев, выкладывайте свежие принтскрины в форум.

Ну и коль скоро задачку вы решаете по своей инициативе, то выбор простого и удобного средства для "карманной БД" вполне может быть сделан в пользу Аксеса, если полный орфис на машине уже и так есть.

У вас у Прибора может быть только одно свойство. В реальности этого может быть недостаточно.
Свойства объектов в простейшем случае обычно задаются 3 таблицами.

Таблица Прибор
идПрибора - ПК автосчетчик
НаименованиеПрибора
СерийныйНомер
... остальные поля

Справочник Свойств
идСвойства - ПК автосчетчик
НазваниеСвойства - Строка описывающее свойство ("цвет", "вес", "тип", ...)
...

Таблица ЗначениеСвойствПоПриборам
идЗначения - ПК автосчетчик
идПрибора - ФК ссылка на прибор
идСвойства - ФК ссылка на Свойство
СтрокаЗначения - Строка, хранящая значение Свойства для Прибора ("красный", "10,25", "переключатель")

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

У вас очень бестолковая система наименований полей и таблиц. Смесь латиницы и кириллицы, пальцы сломаешь. В разных таблицах поля имеют одинаковые названия, когда они соберутся в запросе, будет неудобно. Я бы именовал ПК по имени таблицы с добавлением префикса/суффикса "ID". Поле ПК и поле ФК, через которые идет связь, должны иметь одинаковые имена. В названии таблиц и полей использовал бы латиницу (английский). Поле ПК DeviceID в таблице Device (прибор) и ФК DeviceID в таблице Movement (движение), аналогично MarkID (маркировка), PropertyID (свойство) и т.д. Это вкусовщина, но гораздо легче читать схему и проще трассировать запросы, когда имена присвоены по четкой системе.