MX -- ALEX
EXCEL - только интерфейс для ввода-отображения - без формул

Сомнительная идея. Еще для отображения чего-то обобщенного из хранилищ данных в Йексель куда ни шло. Может аналитик потом это общитывать. Но для ввода в OLTP системах - явно применение средств не по назначению. Это тока у нас могли додуматься, чтобы сэкономить на разработке настоящих клиентов.

SergSuper
Этим Вы признаёте преимущество Экселя как средства для разработки клиентов: если экономится время - чего ж в этом плохого?

В том, что это не специализированное средство для разработки клиентов систем поддержки оперативно прикладных процессов. (Т.е. применение средст не по назначению - электронного кулькулятора, для клиента ввода данных в БД). Если у вас есть пушка, то это дешевле, чтобы стрелять по воробьям, чем делать ружье. В целом на всех этапах ЖЦ может быть не только не дешевле, но и вообще иметь в последствии значительные ограничения по решению задач по ходу.


SergSuper
Зачем тратить время на разработку своих настоящих клиентов когда есть по-настоящему настоящий клиент?
Я пытался поставить под сомнение именно настоящность такого клиента и противопоставить настоящим.

SergSuper
Следущий шаг в этом направлении - признать Ексель как полноценное средство хранения и обработки данных

Вот я гАвАру, что это хороший электронный калькулятор и только. Для этого он и создавался буржуа.
Как-то лет 10 назад парни толкали бухгалтерскую систему на Йекселе для небольших бухгалтерий. Поди плохо? Налабали не долго парясь и толкают себе.
Сделали рекламу. Все как надо.


SergSuper
А вобще глупо писать серьёзные вещи в заведомо несерьёзном топике

Кто знает. Может в этом мире все глупо в конечном счете.

MX -- ALEX
фишка - в матричном построении транзакций
TQM - самоТрансформирующиеся Матрицы Запросов

Это что-то из технологий Кэша? Или что? Что-то никогда про такую траблу не слышал. Это часом не какие-то ранние эмуляции MOLAP? Какиенибудь Крос-запросы или что-то из этой серии? В инете не нашел ничего, кроме ссылок на Ваши тексты на этом форуме.

MX -- ALEX
это наша авторская разработка
mx@enters.eu
Она компенсирует какие-то недостатки Кэша?

Все же Йксель как клиент БД, скорее всего не лучшее из лучшего. У самого MS Аксцесс претендует быть клиентом для Скуля. Да и не только у MS (в справке у Оракла про Аксцесс что-то мелькало). А Йексель больше для анализа обощенных данных в хранилищах данных, например для ОЛАПа. А Вы как бы пошли все же специфическим путем.

Имеется в виду - предпочел из тулсов офиса, куда входят и Аксцесс и Йекскль.

MX -- ALEX
метод TQM -
обьединяет все запросы, находящиеся в ячейках матрицы EXCEL
и одним блоком передает их на сервер

все ответы сервера также в виде матрицы - и тоже одним блоком -
возвращаются запросившему EXCEL-клиенту,
где ТОЧНО раскладываются по соответствующим ячейкам-запросчикам


Если речь идет об опреативной работе, то не совсем ясен прогматизм такого метода - там как правило нужно по одному запросу, но оперативному (чтобы он не был устаревшим). А тут у Вас похоже именно на какие-то отчеты типа квартальных или годовых. Иначе они устареют пока юзер будет их все просматривать, да и нужны не все, а выполняется вся группа и все такое. Т.е. это в сторону инструментария по работе с хранилищами данных, а не БД.

MX -- ALEX
при этом обе матрицы - на клиенте и на сервере -
трансформируются - например, чтобы вставить таблицы,
но соответствие ячеек матриц запросов и ответов - сохраняется !

это резко поднимает скорость работы и снижает трафик сети -
передаются только цифры - форматирование передавать не надо,
т к запросившая матрица EXCEL заранее отформатирована



Детали реализации, пока не выяснено для чего это нужно, ничего не дают, потому что не ясно с чем сравниваем.

MX -- ALEX
многомерные аналитические кубы у нас строит CACHE,
и уже готовые - в виде сечений - возвращает клиенту,
одной директивой MX, поданной из одной ячейки EXCEL
в виде запроса на сервер, можно построить десяток таблиц-сечений,
это более мощный и быстрый механизм, чем собственные
pilot-table EXCEL


Ну, собсно окончательно инструментарий ОЛАП для хранилищ данных. Ну для этого Йксель конечно подходит. Однако, как я писал и у Оракла есть смотрелка на Йкселе, и думаю и других Производителей. У них для ОЛАПа вообще отдельные сервера. У Оракла теперь все в одном сервере, но ОЛАП дополнительная опция в пол цены от всей СУБД.
Т.е. это не клиенты для OLTP ситемы с одной стороны, и Вы конкурируете с тулсами ОЛАП, которые у лидирующих СУБД скорее всего продвинутей в том числе и по реализации. Например, они на физическом уровне СУБД занимаются оптимизацией, а Вы на уровне клиента. Ну и у них для разных систем свои клиенты, а Вы теперь Йексель используете и для всех (и OLTP) ради Вашего ОЛАПа.
Мне, кажется, что в целом (концептуально) если и есть применения у Вашего подхода, то область где они "обыграют" буржуазный подход весьма ограничен.
Главная причина, в том что Вы вынуждены приспосабливаться к существующему функционалу СУБД (т.е. типа заплатка), а они могут менять сам этот функционал.