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

Mr.Fontaine, то есть получается из трёх таблиц слепили одну. С избыточностью информации конечно, ухудшением целостности данных, но зато как ты хочешь

Кот Матроскин, однозначно неудачная (я кстати про это написал), но всё же думаетеся мне, удачнее, чем выделение фактических остатков в таблицу изделий.
Проблемы (особенно первая) описанные Вами присутствуют и при записи остатков в таблицу изделий.
Во-вторых, почему последнюю запись надо брать по времени? А id на что?
Ну а про редактирование, это уж пусть извращаются авторы, раз шибко хочется видеть это поле.
Конечно, при хранении только текущего значения остатков можно просто определить величину изменения при редактировании и записать новое значение в поле остатков таблицы изделий, но ведь при моём варианте после определения величины изменения можно же update забабахивать на все последующие записи движения этого товара в этом магазине.

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

ВыcпрошайкаВот что получается при такой схеме. Ну и где тут остатки по отдельному Магазину(Подразделению) должны лечь?
До этого момента мне казалось, что мы проектируем БД. Оказывается разрабатываем интерфейс...
В данной форме согласен, остатки по магазину не нужны.

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

Выcпрошайка, мнений по схеме БД в этом топике напривилили уже порядочно. Тебе самому выбирать какой лучше. Лично мне кажется, более правильным решение отказа от хранения остатков и справочники должны хранить только справочную информацию.
Так-то полной постановки задачи не было, потому я напишу по тому, что писал ты.
Во-первых, займёмся справочниками.
таблица Категории (id категории, наименование, id родителя)
таблица Изделия (id изделия, наименование, id категории)
таблица Магазины (id магазина, наименование)
ну и одна рабочая таблица Движение (id движения, id изделия, id магазина, дата, направление (расход или приход), количество)
При этом остатки можно вычислить простым запросом, который схематично выглядит так:


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


Вот и всё проктирвование БД по твоеим требованиям
Конечно, при необходимости, можно подобавлять ещё кучу полей и таблиц. Например, в справочники статус изделия, категории, магазина (типа активен, не активен и т.п.)
В таблицу движений добавить единицы измерения в какой единице пришло или ушло изделие. При этом конечно следует создать справочник единиц измерений: id единицы измерения, наименование, id базовой единицы измерения, коэффициент пресчёта в базовую единицу измерения (например, один раз пришло 12 бутылок водки, в следующий раз 5 ящиков водки, чтобы правильно сосчитать остатки требуется иметь возможность перевода бутылок в ящики и наоборот)
Да много что ещё можно добавить при необходимости

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