В продолжение темы картриджи и принтеры.

Оцените, пжлст, такую модель данных.


Справочник "Модели принтеров"
id
тип принтера

Справочник "Типы картриджей"
id
тип картриджа
флаг возможности заправки картриджа (картр. матричников не заправляем)

Справочник "модель принтера <-> тип картриджа"
связь многие ко многим (какой картридж к какому принтеру подходит)

Справочник "сервисные организации"
id
название и координаты организации по обсл. картриджей/принтеров

Таблица "Принтеры"
id
model_id - модель принтера
tobo_id - в каком ТОБО находится
cartridge_id - какой картридж сейчас в нем сидит
Нужно ли это поле?
Если оставить, то забивать его в тригере при изм. табл. движений картриджа.
(для уменьшения ресурсоемкости запросов)
90%, что это поле лишнее...
is_active - флаг(1/0), рабочий ли принтер.
(может ли участвовать в движении картриджей. Точнее, может ли принимать
картриджы - вынять картридж из поломаного принтера можно всегда)

Таблица "Картриджи"
id
type_id - тип картриджа
tobo_id - ТОБО первоначальной приписки картриджа
(справочное поле. Просто указывает чей, вообще, картридж)
Дальше идут вариации структуры...
ПЕРВЫЙ (4 доп. поля state, tobo_id, printer_id,service_id ,
поля заполняются тригером таблицы движений картриджей)
State - состояние картриджа
1 - новый (только купили, лежит в заначке)
2 - в ИТ полный (TOBO_ID указывает в каком ТОБО ждет дальнейшей участи)
3 - в принтере (Printer_id указывает в каком именно)
4 - в ИТ пустой (TOBO_ID указывает в каком ТОБО ждет дальнейшей участи)
5 - на обслуживании (заправка/ремонт Service_id указывает в какой компании)
6 - списан (история картриджа окончена. ID мусорки не указываем :) )

В данном варианте нельзя указать вариант
"пришёл с заправки в отвратительном качестве и отдали на перезаправку"

ВТОРОЙ вариант. (5 доп. полей is_empty, state, tobo_id, printer_id,service_id,
поля заполняются тригером на таблице движений)
is_empty - флаг (1/0) пустой картридж иль заправлен
0 - пустой
1 - заправлен
x - возможны оба варианта
* - значение игнорируется (может быть любым)
state/is_empty
1/x - в ИТ (TOBO_ID указывает в каком ТОБО ждет дальнейшей участи)
2/* - в принтере (Printer_id указывает в каком именно)
1/0 - в ИТ пустой (TOBO_ID указывает в каком ТОБО находится)
3/x - на обслуживании (заправка/ремонт Service_id указывает в какой фирме)
4/x - списан
Новый иль нет картридж можно выделить в отдельное вычисляемое поле
(не бывал ещё в принтере - значит новенький).

ТРЕТИЙ вариант (комбинация заполнения полей(NULL/not NULL)
TOBO_id,printer_id,service_id и флаг is_empty
однозначно определяют состояние и метонахождение картриджа.
Можно отказаться от поля state (сделать его вычисляемым из выше перечисленных)

ЧЕТВЕРТЫЙ[u] вариант.
Отказываемся от доп. полей в таблице картриджей.
Перенести их ([u]TOBO_id,printer_id,service_id ) табл. движений и уже оттуда
вытаскивать вытаскивать последние данные для данного картриджа.


Таблица "движения картриджа"
id
date_time - дата движения
cartridge_id - участник движения
printer_id - в какой принтер отправился работать
TOBO_id - если заполнено, значит картридж пришёл в ИТ.
а вот откуда, принтер или заправка, - нужно смотреть историю)
service_id - ушёл на обслуживание
is_empty - в каком состоянии картридж был при движении

Можно ещё добавить флаг причины отправки в сервис (заправка/ремонт),
но это уже мелочи.

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

А вариант "картридж, на самом деле, не в тот принтер запихнули - надо поменять"
вообще повергает в шок :(

А может в таблицах картриджей и принтеров хранить ссылку на строку табл. движений,
в которой этот объект (принтер или картридж) был задействован?

Отделы, ответственные и т.д. - это частично придумано, а частично "светлое будущее"

Вопрос в 4. Операции + типы (в данном случае, там были бы операции с типом приобретения, перемещения, возврата, передачи в ремонт, на заправку, списание и т.п.)
Как?

Я так понял, что моя таблица перемещений отвратительна?

___
P.S.
Купить и т.д. ... а как же творчество ? :-)

"Операции + Типы."

Вы имеете ввиду убрать поля printer_id service_id tobo_id в отдельную таблицу с полями
Тип_места_назначения (принтер/сервис/склад и т.д. и.т.п)
ID_сего_места

Если так, то пусть функционал пострадает в пользу простоты.

Ещё не могу придумать, какой первичный ключ поставить в таблице движения. (дата_движения + ?)

Дабы определить порядок операций в течении дня и при этом оставить возможность добавлять операции "во вчера". Которые, естественно, не затрагивают более поздние перемещения.

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

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

При сохранении нового местоположения картриджа нужно посмотреть на его предыдущее место (например принтер), оценить сиё место (нет ли там другого картриджа) и т.д.

Значит важно знать не только КУДА картридж ушёл, но и ОТКУДА.

Простая ситуация действительно простая :-)

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

Получается:
Строка операции имеет две одинаковые части (пока о нормализации не говорим) "откуда" и "куда"
При добавлении операции N для картриджа А, нужно найти операцию N-1
и скопировать Откуда(N-1) в Куда(N) ... получается так.

Значит всё одно надо знать ПРЕДЫДУЩУЮ операцию по этому картриджу.
Значит операции должны быть упорядочены.

Я запутался :-) ... как этот учет люди ведут и ничего не теряют.

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

О откуда/куда.
тут я совсем потерялся... как собрать в единую "номенклатуру" картриджи с принтерами и в "контрагентов" фирмы и отделы.

Может пошлёте меня с правильной фразой в гугл?

Понаглею ...
Можно увидеть структуру простейшей таблицы движения (без ответственных и т.д. и.т.п - необходимый минимум и без расширений отдел/подотдел/нижний ящик вощле третьего принтера) ?

boottyНе строка операции, а заголовок операции.Давайте, пока, рассматривать вырожденный вариант "одна операция - один картридж". И о цене пока не думаем - это забота бухов. Без этого заморочек хватает :)
bootty
Кстати, какая принципиальная разница между тем, укажете ли Вы предыдущую операцию (в которой есть пункт Куда) или для каждой будете указывать Куда и Откуда (вместо предыдущей операции).
До этих слов я с Вами полностью согласен.
И по следующей фразе я понял, что я не понимаю...
bootty
Закладываться при определении реального порядка операций на дату или на первичный ключ сам не рискнул бы... (гарантируется ли отсутствие перемещений "задним числом"?)

А КАК!? Как при добавлении (изменении в задних числах) операции гарантировать целостность истории!?

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

И этот ключ не даст мне (из Вашего примера с выходными) вытащить с принтера_1 картридж, который был засунут мною (и потом переставлен юзерами) в принтер_2
Вопрос: можете ли Вы, взяв в руки картридж, определить, какой номенклатуре из базы он соответствует? Если нет, то затея с подобным учетом поможет, но не сильно...Да. Каждый картридж имеет уникальный номер. И вся эта затея и затеяна, дабы знать жизненный путь каждого конкретного картриджа.

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

Я же её вижу с двумя параметрами: что, куда. И так я гарантирую, что цепочка передвижений будет неразрывна.

Второй вопрос , который не дает покоя: "как свести принтеры/фирмы/склады в одну сущность "контрагенты" и принтер/картридж и т.д. в "номенклатура" " и потом во всем этом не потеряться, дабы не отправить фирму в склад :-)))))

Я принтеры(рабочие места) / фирмы / склады(ТОБОшки) не объединял - именно поэтому и завел три поля на каждый тип места назначения.

bootty ? готовыми решениями машину уже загадил немного.

Но, либо мега-навороченое, где разбираться и разбираться,
либо "в течении дня допустимо только одно перемещение" :)
Рассмешила "ошибка" :)

Надеюсь ... я Вам ещё не надоел своими постами.

nosov , выпендрился? Полегчало? Поздравляю!
(Знаки вопроса здесь не предполагают ожидания ответа.)

Под целостностью истории я имею ввиду: "куда" в операции N-1 совпадает с "откуда" в операции N. (для одно и того же картриджа)
Другими словами: "Я хочу проследить всю историю перемещений картриджа. И не хочу в этой истории наблюдать "телепортаций" (оп.N - картридж с склада ушёл в принтер_1; оп.N+1 по этому картриджу - с принтер_2 ушел в фирму А)

Я до этой таблицы, "что, куда, когда, причина" и обрезал всю задачу, ибо пока вопрос стоит о поддержании корректности истории.
bootty
Gordeev_Andry
Ещё не могу придумать, какой первичный ключ поставить в таблице движения. (дата_движения + ?)

Дабы определить порядок операций в течении дня и при этом оставить возможность добавлять операции "во вчера". Которые, естественно, не затрагивают более поздние перемещения.
Кому нужен порядок операций? Какая разница, куда сначала выдали картридж, в бухгалтерию или в кадры? Лучше подумайте, как в самописной системе обеспечивать неотрицательные остатки, например, чтобы избежать ситуации, когда один и тот же картридж выдали в разные места :)

Как выдержать неразрывность перемещений без порядка операций(перемещений) ?

И для решения этого вопроса, я думаю, можно рассмотреть операции и в "вырожденом состоянии".