Neoxа как тогда правильно?
Характеристики ведь у коплектующих разнятся сильно.

Тут куда не кинь, везде клин. :)

Разделите БД на слабосвязанные подсистемы.
Модуль "продажи" оперирует небольшим числом наименований докумнетов, в которых фигурируют не VGA или CPU, а артикулы товаров с названиями. Для бухгалтерии этого достаточно.

Модуль "витрина" напротив оперирует детальными характеристиками товаров.

Модуль "склад" оперирует упаковками, весами, габаритами и т.п. довольно стабильными понятиями.

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

Все типы товаров со своими специфическими характеристиками являются подтипом "товара". Впринципе нет ничего криминального в том чтобы просто добавить колонки к отношению "товар". Объектная СУБД скорее всего так и сделает. Но возможно более удобным в плане конфигурирования будет использование слаботипизированных структур данных, типа XML с последующим построением инвертированного индекса, если таковые поддерживаютмя в СУБД - например Text в ORACLE. В отличии от EAV сущности продолжают храниться в реляционном виде - а вся рутина, связанная с декомпозицией сущности на тройки EAV берёт на себя СУБД и скрывает эту кухню за презентационным слоем операторов контекстного поиска и т.п.

Продажи, скад и витрина соединяются лишь на уровне артикула и названия товара. Артикулы следует разместить в системном модуле "классификаторы", который сведёт коды из разных прикладных модулей воедино и при этом изолирует прикладные модули друго от друга.

nchuyko
- вынесение в отдельные таблицы товаров (таблица товаров должна быть одна)


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

nchuyko
- таблица приходов и расходов должна быть одна (просто меняется знак операции).


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