Но у нас все ходы записаны, считаю важным сохранить для истории:
Цитата:
вот даже зарегался специально. Цфт та еще ерунда. Сейчас изложу свои мысли...
в цфт чудовищная избыточность информации в базе. зачем в проводке хранить не только ИД счета дебета и кредита (что достаточно), но и изображения этих счетов? или зачем в той же проводке хранить ссылки на клиентов по дебету и кредиту, когда завязавшись по счету, можно всю инфу узнать.
ну вот ни дизайна, ни удобства, ни логики нормальной, ни структуры БД, ни скорости работы - ничего нет хорошего. структура БД - это помойка в реальном смысле. с контейнерами которая. создано миллионы таблиц, завязаны самыми хитро... нелогичными связями. порой абсолютно лишеными логики. например, ИЗОБРАЖЕНИЕ СЧЕТА (42301...) хранить в поле MAIN_V_ID(!!!).. изображение хранить в поле ID??? таблицы вяжутся не пойми как. ID может вязаться с любым другим полем типа char... ID должен вязаться только с ID!!!
компилятор цфт вставляет свой код не пойми как. и зачем он вообще это делает. ладно, это фигню можно отключить...
далее. зачем создавать копию таблицы, допустим, клиентов (client) и ХОДИТЬ ПО НЕЙ КУРСОРОМ?? КУРСОРОМ, понимаете! ужас. есть же запросы.
зачем нужно было делать так - всю таблицу забабахать в память и ходить по ней курсором взад-вперед, чтобы доступ был к каждой ячейке прямо из кода
вот нафига? да еще и писано все это ... на ИНТЕРПРЕТИРУЮЩЕМ визуаль бейсике. караул.
все это страшное ... ЕЛЕ-ЕЛЕ ворочается на довольно шустрых оракловых серверах.
в этом ... еще и свой язык прилепили, додумались. который должен нести расширение языка pl/sql. на практике мы имеем здорово урезанный pl/sql.
с зачем-то поменяными основными операторами. например, вместо from здесь in ?? вот отсебятина дешевая. или отсутствие between. или отсутствие join.
и если после перечисления всех таблиц не поставить "all", то результат не ждите. он выдаст типа "aaa.collection_id is null"
хотя нужно ровно наоборот. и даже если вы напишите aaa.collection_id = bbb, то перед вашим кодом цфт воткнет aaa.collection_id is null.
и тут хоть тресни. пока не поставишь после всех таблиц "all" - такая вот логика.
всего этого можно было бы избежать, просто воспользовавшись оператором join. это очень удобная и мощная инструкция. но в pl/plus ее нет.
зато, мы можем курсором, ходить туда-сюда.
ведь не спроста же есть стандарт ANSI SQL. там все команды расписаны и минималистичны. но нет, все пошло своей кривенькой болотной тропой...
все это гвоздями прибито к ворду и экселю. и если у меня нет их, то цфт встанет колом. и не будет работать чуть менее, чем совсем. немного будет, но криво и косо. и ждать ожидаемый результат нельзя. потому, что в этом случае, извергая кучи ошибок, система выдаст какой-нибудь результат (или ошибку), происхождение которого даже сами программеры, порой, не могут объяснить. далее, если у вас нет msoffice, администратор проектов тупа не сможет переносить функционал из разработки в релиз. т.к. при этом генерируются mdb файлы, которые работают только с ms access... ладно.
все это касаемо программистов.
для пользователей не лучше.
в программе всего 16 меню. и все. все остальное скрыто в портянках подменю, в которых черт ногу сломит. реально портянки.
и эти портянки даже не отсортированы по какому-либо признаку. только по алфавиту. просто открываете Справочники и вам на экран вываливается ОГРОМНЫЙ список меню, который не влезает в экран и его нужно прокручивать.
неужели трудно было разбить на подгруппы такое меню? было бы куда нагляднее.
иконки есть (с натяжкой). но все они старые, времен windows 3.1. то есть 16 цветов и 16 на 16 в разрешении. почти все иконки взяты из штатного набора бейсика 6.0. понять что делает кнопка, на которой нарисованы три квадрата и две стрелки к ним подсилу разве что экстрасенсу. и таких иконок - весь цфт. редко когда можно догадаться, что за команда скрывается за кнопкой с подобной иконкой. поэтому иконок очень мало и они чрезвычайно не информативны. вот даже WinRAR для своего проекта заказывал разработку полноцветных иконок. здесь же использовали иконки 90-х годов в недешевом промышленном продукте. да, здесь есть два или три полноцветных значка. только не в тему и не к месту. но порыв, видимо, был. просматривая ужасную структуру бд, я был удивлен открытием... оказывается, вся структура бд - это просто перенесенные в оракл таблицы access!!!
без какой бы то ни было особой оптимизации, устранения избыточности. просто тупо, экспортом и все!
отсюда и чудовищная избыточность, и чрезвычайная медлительность работы системы.
еще бы, фильтры есть, а индексации по искомым полям нет. разумеется все это будет еле ворочиться на любом серваке. и я даже догадываюсь, почему выбрали оракл. потому, что эскуэль уж явно подтормаживал с такой ... структурой.
эта система, не выдерживающая критики и сложных запросов, встает колом при мало-мальски сложном начислении. access - однопользовательская система. и при небольших базах работает довольно сносно. но НЕЛЬЗЯ ПРОСТО ТАК ее структуру копировать в промышленную БД БЕЗ ИЗМЕНЕНИЙ. НЕЛЬЗЯ!!! ...или мы получим цфт.
*все вышеизложенное, конечно, имхо...*
программист, есть собственные разработки по фронт-офису, имею опыт работы с разными АБС более 12 лет.
Видимо поэтому с этих "разные АБС" и переходят на ЦФТ-Банк, потому как
Цитата:
...
в цфт чудовищная избыточность информации в базе...
... ну вот ни дизайна, ни удобства, ни логики нормальной, ни структуры БД, ни скорости работы...
и далее по тексту
На каждом проекте слышу: "Какая у вас плохая система, вот у нас была..."
И совсем другое отношение к системе, когда появляется понимание что делает пользователь. _________________ всегда есть как минимум 2 выхода
Ср Апр 09, 2014 10:22  Re: вброс на банкире.ру
Спасибо, поржал.
Сначала читал и подбирал аргументы, потом подумал - вот же лошара, таких простых вещей не знает (это про декомпозицию и признаки all, collections), а потом дошло.
Текст - спецом постебаться выложен.
Так что всё пучком, так держать!
Ср Апр 09, 2014 10:45  Re: вброс на банкире.ру
Random пишет:
Спасибо, поржал.
Сначала читал и подбирал аргументы, потом подумал - вот же лошара, таких простых вещей не знает (это про декомпозицию и признаки all, collections), а потом дошло.
Текст - спецом постебаться выложен.
Так что всё пучком, так держать!
Не знаю, почему сюда зашла... Но поработав некоторое время в большом банке, могу сказать, что к сожалению, IBSO подходит только для очень умеренных банков, а с большим количеством данных справиться не может.
И претензии к PL PLUS есть, и весьма оправданные. Давала посмотреть текст операции одному из разработчиков Яндекса. Отправил куда подальше. Над проблемами работоспособности при большом объеме данных, скептически ухмыльнулся.
Да и про избыточность - могу сказать про пользовательскую. Когда настройки возможны в нескольких справочниках, а еще могут быть прибиты гвоздями в HOOK'ах, то свести концы с концами весьма затруднительно. А возможность плодить расширения и хуки значительно усугубляет проблему. Гибкость - хорошо, но сопровождать эту систему невозможно без чтения кода.
И не, коллеги, это мало похоже на вброс. Конечно, работаем с тем, что есть, но смеяться над очевидными минусами системы вместо того, чтобы признавать и бороться - как минимум несовременно.
Не знаю, почему сюда зашла... Но поработав некоторое время в большом банке, могу сказать, что к сожалению, IBSO подходит только для очень умеренных банков, а с большим количеством данных справиться не может.
Могу поспорить. Например Сбербанк работает на ЦФТ-Банк. Банк ТОП-1. с его объемами очень сомневаюсь, что сравнится хоть один банк.
Chiffa пишет:
И претензии к PL PLUS есть, и весьма оправданные. Давала посмотреть текст операции одному из разработчиков Яндекса. Отправил куда подальше. Над проблемами работоспособности при большом объеме данных, скептически ухмыльнулся.
А какой код показывали? PL SQL или JAVa? т.к. на компилятор в зависимости от платформы компилит их в эти языки. Согласен, что компилит корявенько, но тем не менее.
Chiffa пишет:
Да и про избыточность - могу сказать про пользовательскую. Когда настройки возможны в нескольких справочниках, а еще могут быть прибиты гвоздями в HOOK'ах, то свести концы с концами весьма затруднительно. А возможность плодить расширения и хуки значительно усугубляет проблему. Гибкость - хорошо, но сопровождать эту систему невозможно без чтения кода.
Не прибивайте в Хуках гвоздями. Заводите настройки и обрабатывайте их в Хуках. Тут все зависит от разработчика.
Документируйте изменения.
У меня на последнем проекте около 3 ГБ проектной документации где все расписано вплоть до размерности поля в таблице. Поэтому в код лезть не требуется, достаточно просто посмотреть документы. Так что, все в ваших руках.
Chiffa пишет:
И не, коллеги, это мало похоже на вброс. Конечно, работаем с тем, что есть, но смеяться над очевидными минусами системы вместо того, чтобы признавать и бороться - как минимум несовременно.
Так предлагайте варианты. Делов-то. На проектах слышу много негатива. Если критика конструктивна и конкретна, то всегда стараемся прислушаться и устранить причины этой критики. если просто кричат, что все плохо - то соответсвенно, ни кто это не слушает. _________________ всегда есть как минимум 2 выхода
Не знаю, почему сюда зашла... Но поработав некоторое время в большом банке, могу сказать, что к сожалению, IBSO подходит только для очень умеренных банков, а с большим количеством данных справиться не может.
И претензии к PL PLUS есть, и весьма оправданные. Давала посмотреть текст операции одному из разработчиков Яндекса. Отправил куда подальше. Над проблемами работоспособности при большом объеме данных, скептически ухмыльнулся.
Да и про избыточность - могу сказать про пользовательскую. Когда настройки возможны в нескольких справочниках, а еще могут быть прибиты гвоздями в HOOK'ах, то свести концы с концами весьма затруднительно. А возможность плодить расширения и хуки значительно усугубляет проблему. Гибкость - хорошо, но сопровождать эту систему невозможно без чтения кода.
И не, коллеги, это мало похоже на вброс. Конечно, работаем с тем, что есть, но смеяться над очевидными минусами системы вместо того, чтобы признавать и бороться - как минимум несовременно.
Админ, перенеси в Юмор, Танюшка жжет с первых строк "Не знаю почему сюда зашла".
А я согласен с автором. По большому счету. Изобретение своего языка - спорное решение. Чистый pl/sql, пожалуй, лучше бы подошел.
Привыкли. Уже и не замечаем, как пишем in вместо from. Вот нафига?!
all добавляем, не задумываясь, даже если есть явно условие по collection_id. А не добавишь - компилятор ничего не скажет. Все хорошо, красиво, правильно, но не работает. И пока не переключишься по F12 на pl/sql не поймешь в чем дело.
И постоянно находим грабли. Даже после многих лет работы. Типа если pragma error, то параметра нет, а если debug_pipe, то параметр есть... А почему? Потому, что с промышеленными языками работают сотни тысяч разработчиков. И если такие грабли не исправлены, то по крайней мере описаны. Можно "гугля спросить". А на pl/plus, сколько разработчиков пишет? Тысячи две? Или меньше? Гугля можно не тревожить зря. Если и находит одно упоминание, то на www.cftclub.ru...
Могу поспорить. Например Сбербанк работает на ЦФТ-Банк. Банк ТОП-1. с его объемами очень сомневаюсь, что сравнится хоть один банк.
Вот да, именно там я и работала. И именно потому я такого мнения. В подробности я вдаваться не могу, но скажу, что ребятам очень сильно пришлось потрудиться чтобы IBSO хоть как-то ворочалось под грузом данных Сбера.
Alexsey пишет:
А какой код показывали? PL SQL или JAVa? т.к. на компилятор в зависимости от платформы компилит их в эти языки. Согласен, что компилит корявенько, но тем не менее.
Я показывала код до компиляции, именно PL PLUS.
Alexsey пишет:
Не прибивайте в Хуках гвоздями. Заводите настройки и обрабатывайте их в Хуках. Тут все зависит от разработчика.
Документируйте изменения.
У меня на последнем проекте около 3 ГБ проектной документации где все расписано вплоть до размерности поля в таблице. Поэтому в код лезть не требуется, достаточно просто посмотреть документы. Так что, все в ваших руках.
Весьма похвально, но лично я с подобным ни разу не встречалось. Даже простую вещь, как штатный комментарий в операции, видела в единицах операций. И то, лишь у старой закали Новосибирцев.
А гвоздями прибитые хуки - последствие очень жестких сроков внедрений, когда на документацию нет ни у кого ни сил, ни времени.
Alexsey пишет:
Так предлагайте варианты. Делов-то. На проектах слышу много негатива. Если критика конструктивна и конкретна, то всегда стараемся прислушаться и устранить причины этой критики. если просто кричат, что все плохо - то соответсвенно, ни кто это не слушает.
Дождаться новый продукт на JAVE? Уже не за горами, говорят. Ибо я - горе-прикладной программист, вынужденный разбираться в коде, а никак не низкоуровневый архитектор-разработчик-Бог, которым многие участники данного раздела себя считают.
P.S. И да, all - просто выбесил, когда я писала простой селектик первый раз.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB