Навижен сильно недоделан (С) Gmc. Почему?

[artkashin]

Цитата:

Сообщение от mazzy

Куда перенести ваши пункты? Когда сделают, то вы будете считать Навижин нормальным или отстойным?

я буду считать, что Навижн имеет нормальную среду разработки. И только.

Цитата:

Сообщение от mazzy

Ой, не надо...
В Аксапте есть. Убил бы. Пользователи ищут и сортируют по странным комбинациям полей. Блокируют систему нафиг из-за full scan'ов... А запретить там нельзя...

Хм.. Все же для меня это не довод. Если так пойти, то и фильтровать по полям, не входящим в ключи, надо запретить. Нужен компромисс. Но, добавлять ключ в таблицу (изменение объекта!), даже если его не собираешься создавать на SQL, только для того, чтобы пользователь мог отсортировать, например, Товар книгу Операций по дате учета (ведь все с этим сталкивались!!) - я считаю это крайним случаем.
Конечно, можно скопировать данные в эксель, и там отсортировать.. но ведь это не выход!
Как вариант - пусть останется ограниченный выбор сортировок, но легко настраиваемый администратором, а не вшитый в структуру системы. Ведь от таких вещей и возникает ощущение у пользователей Navision как "недоделки".

Цитата:

Сообщение от mazzy

Ой, не надо...
http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/

Вкратце: реляционные СУБД отвратительно работают с иерархиями.
С появлением treeView либо придется много программировать (перехватывать события expand, collapse), либо смириться с тормознутостью этого контрола при первоначальной загрузке огромного количества данных.

В той же самой Аксапте есть дерево для загрузки прав доступа... Блин... Застрелить хочется разработчиков.
Есть и сложно написанные деревья - клоичество кода огромно.

Я не предлагаю его использовать везде и вся. Только в тех местах, где это оправдано, там же, где и сейчас используются псевдодеревья: Комплекты, План Счетов, Измерения и Анализ по измерениям, BOM.

Цитата:

Сообщение от mazzy

В обход триггеров?
Ой, нафиг, нафиг.
Если триггера должны работать, то все равно будет работа с каждой записью

Тут нужно, чтобы триггера были на уровне СУБД.
А это совсем другая система.

Причем триггера на ПОЛЯ. В этом вижу главнейший недостаток переноса бизнес-логики на сервер, допустим, MS SQL. Добавь Микрософт возможность установки триггера на поля (правда, я плохо представляю работу SQL-запросов в этом случае - но не думаю, что это неразрешимо в принципе) - и он бы с 100% успехом мог бы использоваться как крутейший сервер приложений.

А по поводу SQL запросов - для начала хватило бы и функциональности SELECT (хотя аппетит приходит во время еды). Я же говорю, ШТАТНО. Даже, пусть он работает с каждой записью отдельно, пусть парсит запрос и обрабатывает его по-строчно. Не хватает мощи языка запросов при работе с данными! Пример, язык запросов 1С. На дворе 21 век, а приходится данные из двух табличек, которые легко объединяются по какому-то полю, обрабатывать построчно на форме.. да так, что потом по этому полю и фильтровать нельзя.

Цитата:

Сообщение от mazzy

А отлаживать и вызывать кодеюниты вы как собираетесь?
Или вы предполагаете только статику?

Это будет совсем другая система.

Говорю, это спорный вопрос. Меня больше смущает тот факт, что Навижн впринце не поддерживает целостность данных. Он поддерживает текущую целостность данных, т.е. только новые вводимые данные проверяются на целостность. По коду, куча мест где существует знак := а не VALIDATE, А при удалении записи справочника, например, Учетной группы Клиента, в базе остаются записи, которые ссылаются на несуществующую учетную группу. Отчеты по компрессии данных вообще превращают жизнь в веселье. Т.е. в этом логика системы - не иметь целостности, не иметь точных данных, а иметь лишь некие укрупления, с приемлемой долей погрешности. Это хорошо для Финансовой системы, но , на мой взгляд, плохо для системы управления предприятием.
Остается только и делать, что проводить Тест БД... и то он не всегда помогает.

Цитата:

Сообщение от mazzy

Хм... вы в курсе чем отличается веб-системы от gui-систем?
веб-системы работают в режиме вопрос-ответ.
клиент задает вопрос, сервер отдает ответ.
никаких динамических пересчетов, изменений режима редактирования и подсказок.
вернее можно. Но на клиенте должен присутствовать код, который делает мелкие запросы к серверу и управляет ответами.
Это совсем другая система

Извините, AJAX уже перешагал планету несколько раз. Построить полноценную Веб-систему можно. А самое главное - Нужно. Наличие веб-интерфейсов на уровне заполнения анкеты никого сейчас не устроит.

Цитата:

Сообщение от mazzy

Может быть, лучше просто взять Visual Studio?

Надеюсь на то, что они полноценно "синтегрируют" визуал с навом. Пока я не представляю, как это можно сделать.
Просто не понимаю, почему имея столько свойств контролов, можно управлять только парой?

Цитата:

Сообщение от mazzy

Нах, нах, нах.

Это лишь пожелание. Не будет - не расстроюсь.