1С устарела в доменах данных?

Когда я проектировал Free 1s, столкнулся с архитектурной проблемой.

Что сделать, один документ поступление товаров (с видом операции от поставщика, возврат от покупателя, прием на хранение, прием на комиссию)

Или четыре документа:
Поступление от поставщика, возврат от покупателя, прием на хранение, прием на комиссию.

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

Спросил у ИИ, оно ничего толкового не сказало, так как это сейчас грамотно проектируется (не в 1С конечно)?

Ответ ИИ

Такие базы данных и подходы к организации данных называются объектно-ориентированными или объектно-реляционными базами данных.

————————

📚 1. Объектно-ориентированные СУБД (OODBMS / ООБД)
Базы данных, которые изначально проектировались вокруг парадигм ООП (классы, полиморфизм, наследование, инкапсуляция).

⦁ Суть: В таких СУБД нет традиционных таблиц в реляционном понимании. Вы создаете класс Документ, объявляете дочерние классы ПриходнаяНакладная и РасходнаяНакладная, и они напрямую сохраняются в хранилище как объекты.
⦁ Примеры: InterSystems Caché / IRIS, ObjectStore, db4o, Versant.
⦁ Минусы: На практике чистые ООБД сейчас используются редко из-за сложности построения произвольных аналитических выборок, агрегаций и стандартизации (SQL в них заменен на OQL или языковые API).
————————

📚 2. Объектно-реляционные СУБД (ORDBMS)
Реляционные базы, в которые встроена поддержка объектных концепций (включая наследование таблиц на уровне движка).

Самый яркий и популярный пример — PostgreSQL.
В PostgreSQL есть нативное наследование таблиц (INHERITS):

-- Базовая таблица
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    doc_number VARCHAR(50),
    doc_date DATE,
    status VARCHAR(20)
);

-- Таблица-наследник
CREATE TABLE incoming_invoices (
    incoming_number VARCHAR(50),
    incoming_date DATE,
    counterparty_id INT
) INHERITS (documents);

-- Таблица-наследник
CREATE TABLE outgoing_invoices (
    outgoing_number VARCHAR(50),
    outgoing_date DATE,
    counterparty_id INT
) INHERITS (documents);

⦁ При запросе SELECT * FROM documents база вернет все документы (и базовые, и приходные, и расходные).
⦁ При запросе SELECT * FROM incoming_invoices вернутся только приходные со всеми своими и унаследованными полями.
————————

📚 3. ORM-паттерны в классических реляционных БД (RDBMS)
В современной промышленной разработке чаще всего используют стандартные реляционные СУБД (PostgreSQL, MySQL, MS SQL, Oracle), а само наследование реализуют через слой ORM (Object-Relational Mapping).

Описанная вами задача решается одним из паттернов Мартина Фаулера (Inheritance Mapping Patterns):

1. Class Table Inheritance (Joined Table Inheritance):
  ⦁ Создается таблица documents с общими полями (id, number, date, status).
  ⦁ Создаются отдельные таблицы incoming_invoices и outgoing_invoices, где первичный ключ id одновременно является внешним ключом (FOREIGN KEY) к documents.id.
  ⦁ При выборке конкретного документа ORM делает JOIN, а при выборке общего реестра читается только базовая таблица.
2. Single Table Inheritance (STI):
  ⦁ Все поля всех типов документов хранятся в одной таблице, плюс поле type (дискриминатор). Поля, специфичные для конкретного подтипа, остаются NULL для остальных.
3. Concrete Table Inheritance:
  ⦁ Каждая накладная живет в отдельной таблице, полностью дублируя общие поля базового документа.
————————

📚 4. Документоориентированные NoSQL БД
Если вам важна гибкость схемы (schemaless), когда базовые атрибуты общие, а специфичные зависят от типа:

⦁ Примеры: MongoDB, Couchbase или реляционные БД с колонками JSONB (PostgreSQL).
⦁ Суть: В единой коллекции документов хранятся JSON-объекты. У всех документов есть поля number, date, status, но в зависимости от типа структуры документа вложенный объект attributes содержит индивидуальный набор полей.