Цитата:
Сообщение от
macklakov
Если не ошибаюсь, этой математике порядка 30-40 лет и создавалась она под конкретную задачу.
"ЛАТИНСКИЙ КВАДРАТ, квадратная таблица n2 чисел, каждая строка и каждый столбец которой содержат числа 1, 2,..., n. Напр., для n = 3
2 3 1
3 1 2
1 2 3
Латинские квадраты применяются в комбинаторике.
ЛЕГИОН, в древнерусском счете 100 тыс.
ЛЕЖАНДРА МНОГОЧЛЕНЫ, специальная система многочленов, ортогональных с весом 1 на отрезке [-1;1].
Рассматривались А. Лежандром и П. Лапласом (в 1782-85)."
http://mathforall.narod.ru/formuls/1.10.htm
Для себя поинтересовался историей данного вопроса... однако, не менее
двух столетий.
Цитата:
Сообщение от
macklakov
Хотя, наверное, для Вас мои слова звучат как ересь, особенно, если учесть, что SAP появился благодаря появлению РБД, а появление РБД было вызвано в первую очередь учетными системами...
Кроме SAP у меня еще девять лет опыта работы с продуктами MBS.
Поддерживаю вашу мысль, прикладные языки XAL (Конкорд от Damgaard), C/AL (Navision) из семейства 4GL являются интерфейсами к РБД или тем, что называют СУБД. Аксапта со своими средствами разработок не избавилась от триггеров, форм, запросов и прочих элементов СУБД. Что не позволяет противопоставлять ООП и РБД. Не согласны?
Цитата:
Сообщение от
macklakov
Подтверждение недостаточности реляционной архитектуры, можно увидеть в любой промышленной СУБД. Сложные языки хранимых процедур, тригера, вьюхи, это эмуляция объектного подхода. Прямое изменение данных таблиц считается дурным тоном, т.к. часто эти изменения должны отразиться еще в несколько таблиц, а до конца структуру данных не знает никто.
Полагаете аксапта с ООП избавилась от всего выше перечисленного?
P.S. я согласен с вами только в той мысли, что идет смена технологий и платформ. СУБД все больше скрывается от пользователя и даже разработчика за фасадом новых интерфейсов, объектами разных технологий и способов интеграции бизнес приложений на уровне абстракций.