powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Выбор языка программирования
25 сообщений из 52, страница 2 из 3
Выбор языка программирования
    #34232921
Akni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо всем за отзывы.
Отвечу на некоторые комментарии:

авторЛАБ может коннектится к любой СУБД, поддерживающей ОДБЦ

использование ОДБЦ категорически нежелательно

авторНаконец, для полноты картины можно упомянуть Delphi/Kylix. Но не думаю, что это хорошее решение для данного случая; Kylix - штука мертворожденная и неподдерживаемая, ничего серьезного на нем не писали.

В этом вы абсолютно правы. При всей моей любви к Delphi, Kylix в качестве возможного решения не рассматривается именно по этим причинам

авторА кто будет разрабатывать Ваше "корпоративное приложение"? Внутренние специалисты?

Внутренние специалисты. Сейчас они (и я в т.ч.) занимаемся поддержкой и доработкой корпоративного приложения, написанного внешним вендором много лет назад на VB и частично на Delphi.
Существенными знаниями в java/PHP/C никто, увы, не обладает. Соотв. курсы будут фирмой обеспечены.

авторНу а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение...

ну а это ВЫ, по-моему, зря. Грамотные ХП и хорошо розданные права доступа, имхо, во многих отношениях лучше, чем громоздкий клиент
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34233086
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pavelvpДля DB2, например, ODBC является компонентом прямого доступа.
Ничуть не возражаю. Как не возражаю против ADO-доступа к MSSQL.

Но читайте фразу, на которую я отвечаю:

м. ЛАБ может коннектится к любой СУБД, поддерживающей ОДБЦ.
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34233902
paul310
Ну а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение...

А у меня есть положительный опыт реализации бизнес логики в базе. Правда это было организовано определенным образом: логические объекты с методами и свойствами (вплоть до отчетов). Унаследованные свойства от других объектов. Все это реализовывалось в хранимых процедурах. Клиент с базой работал через один системный класс(таблица в памяти с встроенными методами вызова хранимых процедур). Работа по клиенту заключалась в рисовании интерфейса. Для получения данных содается объект, которому задавалось назнание логического объекта и нужные свойства. И т.д.
Очень удобно в разработке. Проетировщик проектирует логическтй объект, программист БД пишет интерфейс в виде ХП. Физическую реализацию может менять по своему усмотрению и при необходимости. Программист клиентской части быстро рисует интерфейс. У нас человек клинета делал вообще не зная SQL :) Детали интерфейса отработаны так, что процентов 80 изменений в проекте не затрагивали клиента. Даже добавление свойств в логический объект автоматически отрабатывалось в интерфейсе. Внутри объектов встроенные системы разграничения полномочий (навернутая), журнализация и т.д. Работает весьма эффективно, так как обработка всех данных производится внутри субд. А уж сопровождать (вносить изменения) вообще песня - перегенерил процедуру прямо при работающих пользователях...
А наличие описания логических объектов (которые естественно регестрировались в системе) обеспечивает хорошую документированность системы.
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240038
anjey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А в DB2, однако в качестве языка хранимых процедур можно использовать Java ;)
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240055
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akni
авторНаконец, для полноты картины можно упомянуть Delphi/Kylix. Но не думаю, что это хорошее решение для данного случая; Kylix - штука мертворожденная и неподдерживаемая, ничего серьезного на нем не писали.

В этом вы абсолютно правы. При всей моей любви к Delphi, Kylix в качестве возможного решения не рассматривается именно по этим причинам


Насчет Kylix - это печальный, но факт.

Но что либо более адекватное, чем Delphi (и база, и наборы инструментария третьих сторон) - в настоящее время - не существует (кроме номинальных возможностей в .NET).

Рассматривать Java инфраструктуру в "доступном массам" виде - тем более бессмысленно. Реально используемые практиками (как правило, очень большими компаниями) инструменты - мало имеют отношения к тому, что активно популяризуется в прессе и в "общественном мнении". Профессиональный же уровень (WebLogic и WebSphere), требует огромных финансовых вливаний (в лицензии, в обучение, в поддержку) с весьма непредсказуемым результатом.

Akni
авторНу а бизнес-логика живущая в базе - это, ИМХО, крайне неграмотное архитектурное решение...

ну а это ВЫ, по-моему, зря. Грамотные ХП и хорошо розданные права доступа, имхо, во многих отношениях лучше, чем громоздкий клиент

Все зависит от используемой СУБД и степени развитости этих языков в ней. Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase). Серверные слои на J2EE или .NET (встроенные) или в виде middleware (внешние) - это огоромный выстрел мимо по любым ТТХ (кроме случая - интеграции крайне зоопарковых/гетерогенных комплексов)

Да, PL/SQL - это дорого, но в данном случае - это как раз лучший случай из категории: "скупой платит дважды, скупой дурак - трижды"

----

Тем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее:

Специфику (основную деятельность) бизнеса - лучше автоматизировать самим.

Как правило, сюда попадают блоки:
- продаж (+ CRM)
- производства (впрочем, зависит от вида оного, к примеру - в случае дискретного производства - есть смысл взять готовый блок технической подготовки и нормирования)
- логистика (как ни странно, но ее лучше - реализовать самому)

В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия), к примеру:
- бухалтерский учет (вернее налоговый и консолидированный)
- учет ЗП (именно расчет)
- финансовое планирование и бюджетирование
- документооборот

Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой. К примеру (соотвественно)
-1c,
- 1с или Коминтех,
- ??? (не знаю, не имел дела)
- система Дело (ЕОС)

И о зле "лоскутности" я бы говорить в данном случае - и вовсе не стал бы. Как правило, и в озвученных мной выше продуктах вопросы интеграции - давно решены, и в Oracle и MS SQL гетерогенные сервисы - давно уже отработанная и довольно адекватная тема
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240090
stilet69
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Выскажу свое мнение.
Все же Ява наиболее предпочтительный язык для вас, но... Для разработки своей системы берите готовый open source фреймуорк с активным сообществом. Если совсем с нуля то jboss. Но я бы посоветовал вам обратить внимание на http://adempiere.red1.org Это открытая ERP система в которой уже 80% есть того, что вам надо. Остальные 20% дописать гораздо проще.
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240137
Dmitry V. Liseev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi!

grexhide
Все зависит от используемой СУБД и степени развитости этих языков в ней.
Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы
в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase).
Серверные слои на J2EE или .NET (встроенные) или в виде middleware
(внешние) - это огоромный выстрел мимо по любым ТТХ (кроме
случая - интеграции крайне зоопарковых/гетерогенных комплексов)
А вот тут поподробнее. С чего такой вывод? PL/SQL - далеко не самое
удобное решение для построения серверов приложений с высокой
производительностью. Да и удобство разработки - не очень. Существуют
Cache и другие М-*, которые изначально созданы, как платформы для
построения распределенных серверов приложений, в отличие от Oracle,
DB2 и т.д. Господин MX - ALEX тут уже неоднократно высказывался.
У меня есть свой подход к построению серверов приложений на Cache.
Пока "огоромный выстрел мимо по любым ТТХ" не замечал. Системы
работают быстро, с большими базами (около 200 Гб, 400 конкурентных
соединений), на дешевых серверах, совершенно не требуют
администрирования, обслуживание/обновление - дистанционное.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240152
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry V. LiseevА вот тут поподробнее. С чего такой вывод?

Нет, нельзя. Идите в раздел - Сравнение СУБД и рассказывайте про свою cache.

-

Право, даже не смешно
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240203
anjeyА в DB2, однако в качестве языка хранимых процедур можно использовать Java ;)
Не только в DB2. В Informix тоже и еще C
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34240671
Dmitry V. Liseev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi!

[quit grexhide]Нет, нельзя.[/quit]
Забавный Вы человек: "На яве программировать не умею, про каше вообще
не знаю, потому самая крутая система - Delphi, т.к. только ее я хорошо
знаю".

[quit grexhide]Идите в раздел - Сравнение СУБД[/quit]
Причем тут СУБД? Речь шла о серверной бизнес логике. Или Tomcat
Вы тоже к СУБД относите, потому что он на сервере стоит? Или потому,
что Вы не знаете, что такое Tomcat?

[quit grexhide]Право, даже не смешно[/quit]
Дык, о том и речь.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34241089
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grexhide Dmitry V. LiseevА вот тут поподробнее. С чего такой вывод?
Нет, нельзя. Идите в раздел - Сравнение СУБД и рассказывайте про свою cache.
-
Право, даже не смешно
+1
IMHO в топике не говорится о создании промежуточного сервера приложений.
IMHO ООБД изврат (на данном историческом этапе)
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34241811
Dmitry V. Liseev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hi!

Petro123
IMHO в топике не говорится о создании промежуточного сервера
приложений.
В топике говорилось о том, где и на чем писать бизнес-логику. Вариантов
не так много. Можно делать всю бизнес-логику в клиенте на том, на чем
написан клиент. Можно делать всю бизнес-логику в СУБД на том, на чем
она позволяет (триггеры и хранимки на PL/SQL, T/SQL и т.д.). Можно делать
ее на промежуточном уровне на PHP, Perl, ASP, JSP, Java и т.д.

Petro123
IMHO ООБД изврат (на данном историческом этапе)
"Не читал, но осуждаю" :) Cache не имеет отношения к ООБД. Это просто
платформа для разработки распределенных приложений. Она может как
хранить данные (быть в качестве СУБД, и даже изображать подобие РСУБД),
так и сервером приложений. Как на разных физических серверах, так
и "в одном флаконе".

Можно в качестве СУБД использовать ORACLE, а бизнес-логику писать
на Cache, можно наоборот, хранить данные в Cache, а бизнес-логику делать
отдельно на PHP, Java или еще чем-нибудь (или на клиенте). Можно делать
все в Cache, что существенно удобнее в разработке и сильно быстрее работает.

Единственное, что нельзя делать на Cache, так это клиента. Тут уже
говорилось о варианте, когда в качестве клиента используется Excel,
а все остальное сделано на сервере Cache, есть масса вариантов, когда
в качестве клиента используют браузер (DHTML, JavaScript или JavaApplet),
а все остальное на Cache, есть варианты когда клиентов пишут на Delphi,
C++ и т.д.

На Cache делают программы, которые получают и сохраняют данные
с разных девайсов или с модема через COM, работают с файлами,
парсят и генерят XML, выполняют сложную обработку данных,
включая сложные индексы и поиск (есть примеры построения
полнотекстовых индексов) работают в качестве серверов
или клиентов по TCP/IP (например SMTP, NNTP, FTP и т.д.). Ничего
такого на СУБД сделать просто нельзя, потому бессмысленно сравнивать
Cache и СУБД.

В частности, для разработки этого форума не нужно ничего, кроме
Cache (разве что WEB сервер еще желателен, типа IIS или Apache).
Она может хранить сообщения и файлы, выполнять полнотекстовое
индексирование и поиск, давать доступ как через HTTP, так и через
NNTP.

Просто там язык программирования специально заточен на обработку
данных, в отличие от Pascal, C++, Java и т.д. Но при этом имеет больше
возможностей, чем PL/SQL, соответственно не приходится разводить
зоопарк из разных языков и технологий на сервере.

Собственно, я своих архитектурных решений никому не навязываю.
Просто потом не надо удивляться, почему у одних зарплата считается
три часа на сервере стоимостью 20 килобаксов и требует админа
с зарплатой 3 килобакса, а у других считается 15 секунд на трех
серверах по колибаксу и никакого обслуживания вообще не требует.

Единственное, чего делать не нужно, так это писать новый ответственный
проект на Cache, если Вы о нем раньше не слышали. Собственно, это
относится и к любой другой технологии (Java, C#, .Net и т.д.). Писать
нужно только на том, на чем умеешь и знаешь. А самообразованием
заниматься в отдельное время.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34242245
Akni
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
grexhideТем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее:

Специфику (основную деятельность) бизнеса - лучше автоматизировать самим. ...

В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия)...
Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой

Приблизительно так все и будет выглядеть. Бухгалтерия и зарплата имеют свой купленный софт, его трогать никто не собирается.
Автоматизироваться будет следующее:
-учет клиентов
-обработка заказов (включая их жизн. цикл на предприятии, этапы техн. обработки и т.п.)
-логистика
-выставление счетов

Бизнес-логика предполагается в базе в виде ХП, триггеров и т.п.
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34242366
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akni grexhideТем не менее, наиболее разумным вариантом развития событий я бы назвал примерно следующее:

Специфику (основную деятельность) бизнеса - лучше автоматизировать самим. ...

В остальных же контурах (носящий регламентный общепринятый характер или не связанные с повседневной деятельностью предприятия)...
Лучше применять тиражируемые и хорошо зарекомендовавшие себя решения с разумной ценой

Приблизительно так все и будет выглядеть. Бухгалтерия и зарплата имеют свой купленный софт, его трогать никто не собирается.
Автоматизироваться будет следующее:
-учет клиентов
-обработка заказов (включая их жизн. цикл на предприятии, этапы техн. обработки и т.п.)
-логистика
-выставление счетов

Бизнес-логика предполагается в базе в виде ХП, триггеров и т.п.
+1
конечно, т.к.
- лезть в финансы дорого и на счётчик могут поставить .
А остальные области автоматизации (перечисленные выше) слишком сильно завитсят от вИдения начальством бизнес-правил этих систем.

Правда у всех решений есть недостатки (лоскутная автоматизация). Но применять ли ERP-решения, как более высокий уровень, зависит от масштабов IT-системы.
IMHO
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34242503
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Но применять ли ERP-решения, как более высокий уровень, зависит от масштабов IT-системы.
IMHO

а) реально работающая ERP система - это большая редкость
б) то что работает, зачастую - с таким же успехом попадает под определение лоскутности (рассматривая внутреннюю структуру монстров)

в) есть конечно, варианты "попроще", вроде 1с или Axapta, но им до ERP - как... пешком на юг. Забавно, конечно, но не стоит оно того (надежд).
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34249800
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grexhideВсе зависит от используемой СУБД и степени развитости этих языков в ней. Тем не менее, серьёзно рассматривать что либо, отличное от PL/SQL - я бы в принципе не стал (судя даже по документации от DB2, MS SQL, Interbase).
Не хотелось бы впадать в разворачивающийся флейм, но это несколько запальчивое заявление. Вы знаете, серверную логику не только на Ораклах пишут...


Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34250137
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С появлением .NET FW 3.0, по мере ознакомления с "новыми придумками мокрософтов", меня одолевает(неутихая) фантазия создания КС-системы "терминального" типа: с одной стороны, в mssql 2005 заметно улучшилась работа с XML, с другой - в FW 3.0 (WPF & WF) есть XAML (специализированный для описания UI XML), т.е., сервер вполне может "отплевывать" клиенту XAML'ы, содержащие в себе и данные и описание UI-элементов и код (обработчиков событий и т.п.). Клиент превращает XAML собственно в "часть своего тела" (XamlReader), т.о. клиент получается чрезвычайно "тонким", соотв. вся система - чрезвычайно гибкой... Мда, фантазия еще не умерла...:)

А, ну да, по теме ж главное - основной язык программирования - XML/XAML :)) (разумеется, немножко и t-sql + с# придется использовать ;)
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34250155
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LRА, ну да, по теме ж главное - основной язык программирования - XML/XAML :))

Я видел и такие примеры "кунсткамер" локального масштаба. Генерируемый на/из сервера БД XML (через PL/SQL) и "браузер", на .NET писанный, рендерящий вот это все удовольствие.

Но по массе именно технических причин - я не стал работать с данной компанией и их технологией.

Все это - было красиво в теории. А на практике - нулевая поддержка со стороны... IDE (основное IDE у них было - multiedit). Короче, в газенваген.

---

При том, что XAML - это штука довольно интересная, и, возможно - будет и актуальная (через несколько лет). По одной простой причине - традиционные среды и языки разработки (если не брать WEB) не предусматривают банального (или делают это очень плохо) - масштабирования UI от текущего разрешения экрана.

Об этом даже Тема Лебедев говорил.

-

Но опять же, XAML и иже - это далеко не панацея и не единственное возможное решение. К примеру - у меня уже запланирана серьезная перетряска подхода от жестко-пиксельного кодирования UI дизайна в delphi. Собираются материалы, прорабатываются вопросы автоматического layoutingа (по принципу web-а и его действительно весьма разумного <TABLE> и иже).

И не так уж много труда придется приложить. Другой вопрос же - куда индустрию в целом понесет (те же самые SWT или WinForms-ы....)

---

А проблема то в чем - человек в >40 летнем возрасте - перестает нормально (без напряжения зрения) воспринимать 8-пунктовый Tahoma (MS Sans Serif) шрифт на 17" TFT мониторе (1280x1024)....
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34250422
anjey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LRС появлением .NET FW 3.0, по мере ознакомления с "новыми придумками мокрософтов", меня одолевает(неутихая) фантазия создания КС-системы "терминального" типа: с одной стороны, в mssql 2005 заметно улучшилась работа с XML, с другой - в FW 3.0 (WPF & WF) есть XAML (специализированный для описания UI XML), т.е., сервер вполне может "отплевывать" клиенту XAML'ы, содержащие в себе и данные и описание UI-элементов и код (обработчиков событий и т.п.). Клиент превращает XAML собственно в "часть своего тела" (XamlReader), т.о. клиент получается чрезвычайно "тонким", соотв. вся система - чрезвычайно гибкой... Мда, фантазия еще не умерла...:)

А, ну да, по теме ж главное - основной язык программирования - XML/XAML :)) (разумеется, немножко и t-sql + с# придется использовать ;)

Какие к черту "новыми придумками мокрософтов" - Вы только что описали давно существующую технологию AJAX.... А из "новыми придумками мокрософтов" я могу назвать только ODBC
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34253626
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grexhideЯ видел и такие примеры "кунсткамер" локального масштаба. Генерируемый на/из сервера БД XML (через PL/SQL) и "браузер", на .NET писанный, рендерящий вот это все удовольствие.

Но по массе именно технических причин - я не стал работать с данной компанией и их технологией.
О! Это про нас. Постараюсь отстоять честь конторы.
grexhideВсе это - было красиво в теории. А на практике - нулевая поддержка со стороны... IDE (основное IDE у них было - multiedit). Короче, в газенваген.
Сейчас уже добавился некий новый редактор XMLников клиентской части. Хотя я по привычке пользуюсь multiedit и мне лично это удобнее.
grexhideПри том, что XAML - это штука довольно интересная, и, возможно - будет и актуальная (через несколько лет). По одной простой причине - традиционные среды и языки разработки (если не брать WEB) не предусматривают банального (или делают это очень плохо) - масштабирования UI от текущего разрешения экрана.
А наш "браузер", на .NET писанный, это предусматривает.
grexhideОб этом даже Тема Лебедев говорил.
По-моему, по ссылке немного о другом.
grexhideНо опять же, XAML и иже - это далеко не панацея и не единственное возможное решение. К примеру - у меня уже запланирана серьезная перетряска подхода от жестко-пиксельного кодирования UI дизайна в delphi. Собираются материалы, прорабатываются вопросы автоматического layoutingа (по принципу web-а и его действительно весьма разумного <TABLE> и иже).

И не так уж много труда придется приложить. Другой вопрос же - куда индустрию в целом понесет (те же самые SWT или WinForms-ы....)
Труда уйдёт не так уж и мало. А наша кунсткамера это всё уже умеет. Не торопитесь отправлять ближнего своего в газенваген :)
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34253710
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так_забежал_просто
Труда уйдёт не так уж и мало. А наша кунсткамера это всё уже умеет. Не торопитесь отправлять ближнего своего в газенваген :)

Да нет, спасибо. Но в принципе - я был вполне благодарен этой организации (Китай-город ?) за то, что понял, насколько мне важна такая стандартная для IDE вещь, как Code complete.

Это, конечно, может выглядеть немного странным, но с годами - у тебя вырабатывается масса рефлекторных привычек. А вот сидеть и рисовать в multiedit-е PL/SQL -ный код - это довольно мрачно.

По банальной и простой причине - я никогда не задавался целью помнить, как точно называется вот тот самый 2435-й по счету реализованный метод, поле или имя процедуры.

-

А вот аргументация одного вашего сотрудника, о том, что пакеты лучше писать через SGML (или, не помню, какой то сильно древний язык форматирования), только ради того, чтобы не "делать работу дважды", реализуя пакет и его тело отдельно...... да право, действительно, это весьма осознанный ход, чтобы отказаться от PL/SQL Developer ;))))

При том, что нужно отдать должное - культура производства была очень даже впечатляющая, в целом.

Но увы - то, что для одного может быть удобным, для другого - запросто заблокировать способность к продуктивной мыследеятельности ;))
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34254025
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grexhideА проблема то в чем - человек в >40 летнем возрасте - перестает нормально (без напряжения зрения) воспринимать 8-пунктовый Tahoma (MS Sans Serif) шрифт на 17" TFT мониторе (1280x1024)....
Хм. А много ли Вы видели "простых пользователей", работающих в 1280x1024, да еще и без Large Fonts?
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34254423
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerХм. А много ли Вы видели "простых пользователей", работающих в 1280x1024, да еще и без Large Fonts?
Скажем так - не видел ни одного ;))

С Large Fonts были замечены трудности, местами, даже у Microsoft продуктов ;(
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34582371
MaximZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а просто интересно, что в результате выбрали?
...
Рейтинг: 0 / 0
Выбор языка программирования
    #34583674
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MaximZа просто интересно, что в результате выбрали?
Кобол. :)
...
Рейтинг: 0 / 0
25 сообщений из 52, страница 2 из 3
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Выбор языка программирования
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]