|
27.01.2004, 13:27 | #1 |
Участник
|
Re: опять 1C: чисто технические аспекты...
Ваши вопросы связаны с тем, что вы подходите к системе с точки зрения системного программиста. Если же посмотреть на систему с точки зрения консультанта (или программитса-предметника), то все не совсем так.
Цитата:
Изначально опубликовано ushastik
Читаю доку по Аксапте и не могу отделаться от ощущения того, что система примитивна. Не поворачивается язык назвать ее предметно-ориенитрованной средой. RAD-среда общего назначения. То есть ничего плохого сказать не хочу, все очень продуманно и технически грамотно, но с таким же успехом можно ERP-платформой назвать связку Oracle + Forms, или Interbase + Delphi. Если я чего-то недопонял, ткните носом, как пиписка называется, я не обижусь. Если же вас интересуют процессы, остатки, себестоимости, то в аксапте вы найдете массу готовых классов, которых нет в RAD системах по-определению. В общем, определитесь с точкой зрения и не смешивайте их. Цитата:
Изначально опубликовано ushastik
1. Основа конечного приложения - плоская таблица. Пусть независимая от СУБД, пусть с метаданными и методами, но плоская и тупая. Основа системы - готовые классы, которые работают с таблицами. Работать с таблицами напрямую - моветон. Хотя так делают. Как с точки зрения быстродействия, так и с точки зрения незнания. Читайте бест-практис. Цитата:
Изначально опубликовано ushastik
Например, 1С-программист ничего не знает о реляционной модели. Он оперирует действительно объектами, максимально приближенными к предметной области (учет и анализ). Например - иерархический справочник (дерево). Да еще с поддержкой истории изменения атрибутов. Или - многомерный накопительный регистр. Накапливает ресурсы в разрезе аналитик. Или документ - допустимы вложенные таблицы (документы). Понятно, почему создание простого склада на 1C - это день работы. Аксапта не покупается для того, чтобы делать "простой" склад. Аксапта покупается, когда ищут уже готовый функционал. Аксапту берут в расчете, что уж простой склад там точно есть, когда хотят гораздо большего. Снова определитесь с точкой зрения. Цитата:
Изначально опубликовано ushastik
Реляционная схема хранения создается автоматически, пусть неоптимально, тормознуто (есть над чем работать), но суть в том, что реляционная модель чрезвычайна бедна для отображения реальных понятий учета и анализа. Можно и дерево построить, и регистры многомерные, и историю добавить, и все на плоских таблицах, только я от этого велосипеда устал уже. Но. Когда уровень запросов повышается... Тормознутость, неоптимальность становится уже критическим фактором. И тут выясняется, что тормознутость появляется не из-за того, что в 1С плохие. А просто потому, в выбранной модели быстрее сделать практически невозможно. Цитата:
Изначально опубликовано ushastik
Понятно, почему западные системы так долго внедряются. Постоение небоскреба из кирпичей. А как же блочная технология, господа ? Или я не ту доку читаю ? А какже классы ushastik? А какже готовый функционал? Цитата:
Изначально опубликовано ushastik
Просто в первой главе книжки 1C всегда прописана система понятий. Я по аналогии думаю, что глава "Developing Axapta Applications" тоже должна основы давать, и что я вижу ? Только азы ООП и РСУБД. Цитата:
Изначально опубликовано ushastik
2. Второй момент, который меня давно гложет - ориентация на данные, а не на процессы. Я просто сужу с позиций биллинга - например заключение договора на установку телефона - это документооборот, растянутый во времени, в который вовлечены несколько сотрудников. Причем, у меня закралось сомнение в вашем представлении о СУБД. Процесы в СУБД это по крайней мере две таблицы - сам процесс и подчиненная таблица свершившихся действий по этому процессу. То, что вы описываете делается совсем не так. Даже в Аксапте. Цитата:
Изначально опубликовано ushastik
И 1C для меня технологичнее Аксапты. |
|
Теги |
1c |
|
|