В моем контексте 1С - это платформа интерпретации и исполнения команд встроенного языка 1С (клиентское приложение + сервер приложения). В этом языке нет команд прямого доступа к таблицам БД. При этом не важно, какая именно конфигурация (настройка)используется
1С, судя по всему, не так абстрактна в отношениях с СУБД. Правильно ли я понял, что Application Server SAPа не знает, на какой СУБД хранятся данные системы??? А кто же тогда это знает? Драйвер доступа к СУБД с унифицированным интерфейсом ODBC?

Это не так.

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

Этот опыт привел их к тому, что за свои действия нужно отвечать. Иначе от неграмотных действий бухгалтера, удалившего случайно сотрудника из БД будут большие проблемы у заказчика. Поэтому, с технической точки зрения, из SAP или Oracle стандартными средствами удалить практически ничего нельзя. Апдейтить или очищать таблицы из ABAP-а напрямую практически всегда запрещено (административно). Объекты из справочников можно удалить (как правило), если по ним ничего не было. Документы, проводки удалить нельзя, только сторнировать.
Но это реализовано не средствами СУБД, а в прикладном коде. Контроль наличия соответствующих записей, открытость ID (ключей, кодов) этих записей - все это реализовано на прикладном уровне, а не средствами СУБД. Можно докопаться в отладчике, при большом желании и терпении
Эти системы - для БОЛЬШИХ предприятий. Галактика была двузвенкой. Она задыхалась уже от нескольких сотен тысяч ОС-ов. SAP тогда давно был трехзвенным и посчитать амортизацию миллиону ОС-ов мог спокойно. У него уже была возможность вести учет ОС-ов по разным методам учета. Это было несколько лет назад.
С организационной точки зрения, административный ресурс при внедрении и сопровождении очень силен. Иначе не будет стандартизации бизнес-процесса и его отражение в БД будет зависеть от МарьВанны и Пети, что может быть и допустимо для маленьких предприятий, но не для больших.

Можно. Получается, что нужно разрабатывать ERP-систему под каждую СУБД? Сколько ж тогда было бы клонов SAP?

Сомневаюсь, что это делает СУБД. Это делает прикладной код.
Может мы и под СУБД понимаем разные вещи? СУБД - это платформа. MS SQL, Oracle, Pervasive и т.п. СУБД сама ничего не делает. Она только данные перекладывает с места на место. Это всего лишь велосипед для данных. Полноценное использование средств СУБД, наверное, реализовано только в OeBS.

Насчет докручивания СУБД. Если в СУБД на события прикручивать триггеры - это удел местных разработчиков, а не разработчиков ERP-системы. При этом местные внедренцы должны обладать абсолютным знанием, что делает эта громоздкая система в стандарте и не задевать целостности и логики стандарта, постоянно поддерживать и сверять свое направление доработок с тем, как обновляется и меняется стандарт. Такую ответственность никто на себя не возьмет. Цена системы SAP большая, преедприятие-владелец - крупное, ошибка и недальновидность такого местного внедренца очень вероятна, а ответственность этого внедренца перед владельцами системы - никакая.

В 1С нет команды изменения/вставки/удаления напрямую из таблиц?
Там что, как в VBA, только объектное программирование?

Типа только так и никак иначе: Если Справочник_контрагентов.Контрагент_1.ИНН = '99*' то ...

Или так: Накладные.Накладная_2156.Позиция_[i].Удалить

Прекрасно, но ведь в 1С ВСЕ ТО ЖЕ САМОЕ!!
СУБД в 1С используется только для хранения данных, никакой прикладной логики в СУБД нет!!! Там есть только системная часть логики пересчета регистров, контроля полномочий и.т.д, призванная увеличивать производительность системы
Вся прикладная логика реализована на встроенном языке 1С в виде конфигурации (настройки). Эта настройка хранится в БД наряду с прикладными данными в виде отдельных структур данных и вычитывается на клиент при входе в систему.
Контроль целостности при удалении отдельных записей БД реализован в прикладном коде.
Контроль изменения структуры БД (добавление/удаление таблиц) реализован на уровне Конфигуратора настройки.

Таким образом еще раз прихожу к выводу, что технологически 1С и SAP можно сравнить, но от этого сравнения толку никакого. Основное различие - философское. Скажу больше - из 1С легко сделать SAP. Достаточно на 1С написать новую конфигурацию, в которую впихнуть всю прикладную логику SAP, со всеми его миллионами строк кода, тысячами настроек и параметров. Только вот какой в этом смысл? Кстати, такая попытка уже предпринята в виде конфигурации 1С УПП (Управление Производственным Предприятием). Очень большая конфигурация, все в ней есть, куча параметров и миллионы строк кода.

Может и придираюсь, но где тут соответствие?

Почему? Вы неправильно поняли. Серверная логика 1С - универсальна, она не имеет прикладной окраски. Достаточно просто на сервере приложений хранить наборы серверной логики (триггеров, встроенных процедур и т.д.) для каждой поддерживаемой СУБД. Да, согласен, это довольно хлопотно - постоянно следить за обновлениями производителей СУБД и учитывать это в новых релизах. Но это ведь головная боль фирмы 1С, а не разработчиков прикладных решений. Еще раз повторю - платформа 1С полностью обеспечивает выполнение команд встроенного языка. Как она это делает - это проблема фирмы 1С. Разработчика конфигурации это не должно волновать


Это делает триггер, автоматически размещенный СУБД сервером 1С при создании/загрузке базы в СУБД соответствующего вида. Что в этом сложного? По-моему, вполне нормальный подход


Компания 1С отделила универсальную серверную логику от прикладной логики. Неплохая идея, по-моему. Неужели в других системах этого нет? Зачем тогда все эти навороты в СУБД, если ими не пользоваться?


Да, в 1С только высокоуровневое объектное программирование.
Каждая запись в таблице - это какой-то объект системы, например, какой-нибудь элемент справочника. Чтобы его удалить, нужно обратиться к нему средствами 1С, например методом "Найти(..)". Только потом, при наличии соответствующих полномочий, его можно его удалить методом "Удалить()"

Все правильно - ПРИКЛАДНОЙ логики нет, вся серверная логика универсальная, методы пересчета итогов унифицированы.
Если точнее, то содержимое триггера автоматически обновляется при реструктуризации таблиц-носителей. Делает это платформа 1С автоматически.

Я так понял, что разработчиками системы в триггеры вынесен прикладной код. Триггеры пишутся свои под каждую СУБД. Получается дублирование кода разработчиками? И на каких СУБД может работать 1С?
Галактика и SAP пошли по пути многоплатформенности (СУБД) через создание собственного языка.

Серверная логика - это компилятор языка + триггеры? В целом идея неплохая. Но привязка к конкретной СУБД - очень сомнительное решение, если система позиционируется на мировом рынке для крупной промышленной эксплуатации. Дублирование же кода под разные СУБД - еще более сомнительное решение.

Чтобы пользоваться там, где это необходимо. Для ERP-систем это довольно спорно. OeBS в этом смысле - приятное исключение.

Вряд ли поставщики СУБД вносят настолько серьезные изменения, что из-за этого перестают работать триггеры и встроенные процедуры. Иначе этим никто бы не пользовался.

Виноват, только что уточнил. Вы были правы. Пересчет итогов выполняется не триггером, а все-таки прикладным кодом, вызов которого происходит из сервера приложения.
1С не использует триггеры на MS SQL. 1С использует хранимые процедуры и функции.

Ой как сильно Вы заблуждаетесь... Знаком термин "мутирующая таблица"? Так сам нарывался, во времена писательства под Oracle. Когда делается апдейт Oracle (пределах одной ветки, например 8.0.x), а после этого лихорадочно приходится переделывать логику триггеров.

Отношения к СУБД в 1С и SAP вобщем примерно одинаково, в обоих случаях к БД нельзя обратиться на её родном SQL языке
т.е. есть некий промежуточный SQL язык который затем уже транслируется в язык БД

Шито? В ABAP есть Native SQL, даже триггер можно повесить напрямую.