Инсайт по модели данных
Недавно я читал статьи по моделированию данных и Data Domain.
И внезапно ко мне пришел инсайт — я взглянул под непривычным углом на то, что видел уже много раз.
В 1С есть приходная и расходная накладная. А ведь по сути это один и тот же объект — продажа. Состав полей абсолютно одинаков, потому что операция одна, только отражается или у поставщика или у покупателя.
Поэтому можно было бы делать просто документ Продажа. С признаком отражения у поставщика это был бы аналог расходной накладной, а с признаком отражения у покупателя это был бы аналог приходной накладной.
Понятно, что так делать, скорее всего в реляционных базах данных не будут. А вот в объектных базах возможно.
Кстати, учитывая что операция одинаковая, служебные процедуры тоже похожи, например, пересчеты при комплектации/погрузке товаров у поставщика и пересчеты при приемке у покупателя.
А вот, например, операция перемещения товаров привычно отражается одинаково у отправителя и получателя одним документом «Перемещение товаров».
Никогда раньше об этом не задумывался…
Следующий шаг — ведь поступления товаров тоже не однородны.
Бывают поступления товаров, услуг, на комиссию. Делать отдельные виды документов или поле вида накладной?
Увы, в рамках реляционной модели данных эта задача «красиво» не решается.
Красивому решению мешает кризис IT, который наличествует даже в теме моделирования данных.
Нет, домены данных уже успешно применяются в высоко-корпоративном секторе. Но ведь у большинства пользователей, в основной массе программных проектов, ими даже не пахнет. Инерция в программировании велика, увы.

Ну в некоторых конфигурациях, есть реквизит у документа Хозоперация, который по сути и делает то о чем вы тут задумались, документ один но с небольшим нюансом.
Если наш гений только сейчас знакомится с Data Domain, то безусловно имеет место «кризис IT», правда в одной отдельно взятой голове.
По сути:
1. Надо вырабатывать язык общения и терминологии (привет буквоедам!), понятный всем сторонам процесса. Поэтому для отражения закупок использовать термин «Продажа» несколько неуместно.
2. Сущности должны идти от потребностей бизнеса, поэтому Продажи и Закупки это безусловно разные сущности. А то, что имеется некая общая двойственная картина это детали реализации. Да, можно выделить единую таблицу (сомнительное преимущество), некие общие программные интерфейсы, но в силу все-таки различной специфики — можно легко увязнуть в этих самых деталях. Либо вы держите фабрику, которая генерит объекты под ту или иную операцию, либо у вас весь код унизан условиями Если Операция=.. Тогда. По-моему оба варианты не очень.
3. Сущность «Продажа» — это очень «жирная» сущность, которая отвечает за слишком многое. Такое может сгодится для малого бизнеса (типа «ларек»), но при росте становится понятно, что надо выделить отдельно складскую операцию, финансовую, заказ клиента. Потому что этими данными оперируют разные акторы, в разных местах и разном времени. Тоже самое касается и «перемещения товаров»: расходный ордер + перемещение + приходный ордер.
4. Более мелкие детали возможно не стоит делить: поступление товаров и услуг, а если они приходят одновременно? Возможно взаимосвязано. Здесь могут помочь такие вещи как инверсия зависимостей и паттерны: стратегия, команда и другие.