Надо хранить все в количественном виде и вынести инвентарный номер в отдельную таблицу.
Как вариант:

Таблица складов:

Таблица объектов:

Таблица учета перемещений:

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

Изначально все предметы берутся из особого склада (source_storage_id = 0 или даже NULL), где их в итоге будет минусовое количество.

Похожим образом, лампочки с одним айди перемещаются в любых количествах, отличных от 1, сохраняя общий инвентарный номер.

agentsakhЕсли же сделать по вашей структуре с добавлением поля «откуда» таблицы движения:
1 апреля- айди лампочки-5-склад1-склад2.
2 апреля- айди лампочки-3-склад1-склад3.
3 апреля- айди лампочки-2-склад2-склад4.
Уже наглядней, более понятно движение, но т.к понятие «склад» условно скажем если будет 100 складов и передвижение лампочек со склада1 на склад2, а со склада N и N раз, то тут уже не проследить определенную ветку движения лапочек. Так как параллельно создаются множество других веток движения объекта с одинаковым айди. Проще говоря один объект находится в множестве мест для учета. С условным диваном такое не может быть, а с лампочками получается может. Вот в чем проблема.
Ничего не понятно.
Почему меняются айди лампочек?! Условием задачи было, что айди лампочек должно сохраниться. И где количество?
Приносим сто лампочек на склад 1. У всех один инвентарный номер. Одну лампочку переносим со склада 1 на слад 2, потом со склада 2 на склад 3.
1 апреля - айди лампочки 1 - NULL - склад1 - 100 (принесли сто лампочек из магазина на склад1)
1 апреля - айди лампочки 1 - слад1 - склад2 - 1 (переместили одну лампочку из склад1 на склад2)
1 апреля - айди лампочки 1 - слад2 - склад3 - 1 (переместили одну лампочку из склад2 на склад3)

На складе 1 лампочек стало 99, на складе 2 - 0, на складе 3 - 1. Все лампочки с одним инвентарным номером. Или я неправильно понял задачу или одно из трех.

agentsakhПроблема в том, что при N-операциях c лампочками по N-складам, будет невозможно отследить по таблице движения хотя бы одну ветку движения т.к при запросе по айди объекта вывод будет из всех операций с лампочками.
Ничего не понятно...
Есть же записи, откуда и куда сколько чего относилось. Все можно отследить. В конце концов, если там будут миллионы записей, можно посмотреть только по определенным складам, куда уносилось и куда приносилось.

Я так понимаю, что проблема в следующем:

Одну лампочку перенесли на склад номер два.
И вторую лампочку перенесли на склад номер два.
Потом одну лампочку со склада номер два забрали на склад номер три.

Вопрос. Первую или вторую лампочку забрали со склада номер два?!

В таком случае, у лампочек должно быть по отдельному айдишнику. Иначе никак. Если сложить их количественно, информация потеряется. Можно группировать лампочки по какому-нибудь дополнительному признаку, определять в группы товаров. Количество записей будет довольно большим. И очень смешно будет, например, разделение жидкостей. :D При переносе создавать доп. айди? А какую именно вы краску потратили? Первую или вторую??? :D

Однако в таком раскладе сам учитывающий заблудится спрашивать, а какую, собственно, лампочку собираются перенести на склад номер три?! O_o Этот вопрос лучше осторожно оговорить с заказчиком, нужен ли ему такой гемор.

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

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

id, from_store, to_store, amount, parent_id .

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

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

Сразу замечу, что будет проблема с накопленными перемещениями. Например на склад пришло 5 лампочек, потом еще пять лампочек. А потом с этого склада надо взять десять. А они в разных деревьях. Посмотрите другие типы ветвлений, наверняка вам что-нибудь подойдет. )

Так и вижу вопрос АХЧ:
"А вы краску использовали принесенную со склада номер один в партии номер двенадцать или со склада номер два из партии номер три?"
И круглые глаза работников.

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

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

Кстати, в каком именно виде вы собираетесь вываливать подобную информацию на заказчиков?

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


Вообще никаких проблем.