Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
Доброй ночи.
Вопрос скорее общий.
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?
Пример: нужно сделать транспонирование таблицы, из вертикальной таблицы (month, day_month, contract, sum) сделать что то вроде (month, contract, sum_1, sum2, ..., sum_31), т.е. раскидать суммы горизонтально в зависимости от дня месяца.
Я делаю это в лоб, что то вроде sum(decode(extract day from day_month,1,sum_1)) over (partition by contract) as sum_1 и так далее. Общий смысл думаю понятен.
Такой подход работает, сбоев не даёт, но я вижу, что это некрасиво. И думаю, что более опытный человек нашёл бы более изящное и логичное решение задачи.
Кто как улучшает свой код? Очевидный ответ - опыт. Но возможно кто то читает книги\youtube\сайты по улучшению "шаблонов" своего кода? Кто как двигается в этом направлении, помимо опыта?
Буду благодарен за конструктивные ответы.
21 июн 20, 01:25    [22154425]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
feagor
Member

Откуда: Москва
Сообщений: 255
Arists,

Pivot
21 июн 20, 02:29    [22154431]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
feagor,

спасибо, но мой вопрос скорее общий:)
Пример был дан только для того, чтобы показать, что я понимаю что код не самый лучший.
21 июн 20, 02:44    [22154432]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62522
Блог
Arists
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?

У улучшения кода есть два основных направления. Первое - сделать, чтобы он работал быстро. Для этого есть общие подходы оптимизации - не делать лишнего, думать над алгоритмами и т. п., и есть знание механики сервера: сначала Кайт и далее глубже и глубже. Второе - сделать так, чтобы этот код был хорош в сопровождении (как собственном, так и других). Для этого, пожалуй, лучший способ - практика работы на других языках. PL/SQL язык, прямо скажем, не самый продвинутый, а SQL вообще плохо подходит для сопровождения. Поэтому, варясь в их соку, легко привыкнуть к тому, что так и должно быть. А вот программируя на чём-то ещё и сравнивая - начинаешь думать, как бы и на PL/SQL сформулировать так, чтобы было не хуже других. И постепенно начинает получаться.
21 июн 20, 02:46    [22154433]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Arists
Member

Откуда:
Сообщений: 15
softwarer,

Спасибо за ответ.
Мой вопрос скорее связан не с оптимизацией кода, а с шаблонами проектирования кода.
Попробую объяснить что имею в виду на примере: иногда читаю код других разработчиков. И после прочтения у меня чувство "Барак Обама NOT BAD". И задаю себе вопросы: 1) Понимаю ли я что делает код? Да, понимаю 2) Красиво сделано? Да, красиво 3) Смог бы я сделать эту задачу если бы передо мной её поставили? Да, смог бы 4) Сделал бы я задачу настолько красиво? Нет, скорее всего сделал бы более топорно. Правильно, но более топорно.

То есть, насколько я понимаю, у разработчика из моего примера было бОльшее количество шаблонов, из которых он выбирал когда писал код.

Ответом на свой вопрос я ожидал или ссылку на статью, или возможно ютуб видео или книги.
Тема примерно такая "лучшие шаблоны проектирования кода на PL\SQL".

Я понимаю, что здесь упор идёт на опыт + большее продумывание реализации задачи.
Но возможно есть какие-нибудь материалы, от которых можно отталкиваться.
21 июн 20, 03:22    [22154434]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5365
Arists
Я понимаю, что здесь упор идёт на опыт + большее продумывание реализации задачи.
Но возможно есть какие-нибудь материалы, от которых можно отталкиваться.


Ищем материалы 960-970 г.г. прошлого тысячилетия, на тему структорного/процедурного программирования.
Читаем, проникаемся.

<:o)
22 июн 20, 10:13    [22154960]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 1392
Arists
Я разработчик на PL\SQL, и задумался над вопросом: а как улучшить свой код?

Перестать писать код на pl/sql.
/thread
22 июн 20, 10:46    [22154988]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Michael Isaev
Member

Откуда:
Сообщений: 148
Arists,

1. Поищите в инете соглашения о наименованиях объектов

2. Работая с базой данных Oracle DB:

1. Где только возможно пишите код на SQL (65%)
2. Если вашу задачу нельзя выполнить на SQL, пишите на PL/SQL (25%), особенно с учетом компиляции в нейтив код.
3. Если вашу задачу нельзя выполнить на PL/SQL, пишите на Java (7%)
4. Если вашу задачу нельзя выполнить на Java, пишите на С (3%)

3. Очень редко осторожно применяйте объектные возможности Oracle DB и PL/SQL.

4. Хорошо освойте инструменты наблюдения за производительностью SQL, PL/SQL. Читайте больше литературы про оптимизацию запросов и операций с БД.

5. Если вы решили применять здесь паттерны GoF, GRASP, SOLID, то мимо. Только часть из этих принципов можно применять к PL/SQL.
24 июн 20, 18:29    [22156712]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Elic
Member [заблокирован]

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 29861
Michael Isaev
1. Где только возможно пишите код на SQL (65%)
2. Если вашу задачу нельзя выполнить на SQL, пишите на PL/SQL (25%), особенно с учетом компиляции в нейтив код.
3. Если вашу задачу нельзя выполнить на PL/SQL, пишите на Java (7%)
4. Если вашу задачу нельзя выполнить на Java, пишите на С (3%)
Если бы не было дурацких цифр, то первые два пункта можно было бы принять. А так антинаучный бред. Без обид...
24 июн 20, 18:41    [22156720]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
merch
Member

Откуда:
Сообщений: 167
Elic
Если бы не было дурацких цифр, то первые два пункта можно было бы принять.

В первом пункте тебе какая цифра не нравится? 6 или 5?
24 июн 20, 20:26    [22156790]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Elic
Member [заблокирован]

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 29861
merch
Elic
Если бы не было дурацких цифр, то первые два пункта можно было бы принять.
В первом пункте тебе какая цифра не нравится? 6 или 5?
Ты тоже хочешь казаться оцифрованным дурачком?
Здравый смысл (он же целесообразность) не измеряется процентами.
А те, кто пытаются его измерить, лишены его.
Более того, здравый смысл, зачастую, не играет существенной роли. Потому что представителю от бизнеса нужно поставить дебильную галочку в своё портфолио, чтобы перейти в другую контору и там ещё чего -нибудь развалить.
25 июн 20, 06:42    [22156895]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
merch
Member

Откуда:
Сообщений: 167
Elic, да нет, читаю книжку просто книгу школьную, пытаюсь разобраться, что есть числа, что есть цифры. А теперь ты меня совсем запутал((

А сообщение Микаэля Исаева похоже на выдержку из книги Тома Кайта, без пункта "зачем это вообще делать".
Про проценты, которые он добавил после каждого утверждения. Может он так оценил свои знания С, Java, pl/sql...
25 июн 20, 10:05    [22156980]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
Michael Isaev
Member

Откуда:
Сообщений: 148
merch,

Проценты я поставил, чтобы начинающим был примерно понятен порядок (ну а Elic-а бомбануло и он излишне перевозбудился)

Сейчас бы я еще и Java выкинул бы из этого списка, сократив до SQL > PLSQL > C. Раньше Oracle засадил Java в Базу на волне хайпа (в Oracle DB 9 даже Java EE была или типа того), хотя она там не нужна от слова совсем.

Совет еще один и тривиальный - если параметры и переменные процедур/функций отображаются на поля таблиц, то их объвлять с типом поля table.field%type, а не PLSQL, чтобы при возможном изменении типа полей не искать ошибки, а просто перекомпилировать пакет и автоматом подхватить новые типы.

Совет общий для всех языков и тривиальный - часто используемые процедуры функции выделять в пакеты (обычно это какие-нить xxxx_utils)

Еще Сложные структуры не передавать как параметры процедур, но если передаешь, то передавай по ссылке (nocopy).

Совет общий - больше смотреть код других разработчиков и библиотек, например Alexandria (но не только)

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

Можно еще почитать доку и посмотреть код от Oracle в OeBS - там есть как хорошие примеры так и откровенно антипатерны.
25 июн 20, 12:04    [22157115]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62522
Блог
Michael Isaev
Раньше Oracle засадил Java в Базу на волне хайпа (в Oracle DB 9 даже Java EE была или типа того), хотя она там не нужна от слова совсем.

Она была бы там чертовски нужна, если бы нормально работала.
25 июн 20, 12:07    [22157117]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 1392
softwarer
Она была бы там чертовски нужна, если бы нормально работала.


Пусть лучше отдельно где-нибудь сидит, а то ораклу никакой памяти не хватит.

Сообщение было отредактировано: 25 июн 20, 12:46
25 июн 20, 12:49    [22157146]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47616
Она там неэффективно работала по причине хронической нехватки памяти
(никакой админ не даст ей больше нескольких гигабайт) и по причине морального
устаревания language/jvm. Второй пункт превращает нормального Java-разработчика
в какого-то странного ретрограда. И эффективность взаимодействия с SQL-машиной
под большим вопросом. Те типы данных которые использует Oracle (NUMERIC/VARCHAR2)
на бинарном уровне не совместимы с long, java.lang.String. Тоесть это две совершенно
чужеродные технологии и чтоб они могли эффективно машраллить-сериализовывать
эти структуры через разделяюмую память - надо было об это думать заранее.
27 июн 20, 12:46    [22158179]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62522
Блог
PL/SQL ещё на два десятилетия древнее и ретрограднее. А что касается причин неэффективной работы - не думаю, что мы знаем достаточно, чтобы о них говорить. Факт в том, что если бы Java внутри Oracle работала эффективно - это позволило бы хорошо решить многие задачи и в прямом смысле открыло бы новые горизонты. А вместо этого её встроили сугубо для проформы.
27 июн 20, 13:05    [22158183]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
dmdmdm
Member

Откуда: Нижний Новгород
Сообщений: 1494
В то время как максималисты рассуждают про "проформу" и "моральное устаревание", остальные тупо пользуются жавой .
27 июн 20, 13:37    [22158199]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer,

Вы какой-то технический смысл можете в свои слова встроить?
Какие именно "многие задачи" вы хотели бы на ней решать, и какова та контраформа, которая привела бы вас в восторг.

Меня пока много больше печалит способ, которым были подрублены корни Ada в PL/SQL,
полученные "упрощения" и "удобства" на стороне клиентского PL/SQL по сути отрубают возможности работы
с обобщенными типами данных. В то же время, разглядывание системных пакетов, говорит, что на стороне ядра у PL/SQL открыты
дополнительные возможности, недоступные для клиентского PL/SQL.

В общем, меня не печалит как именно Java встроена в сервер.
Больше печалит отсутствие единства PL/SQL для писателя клиентского кода и системных пакетов.
И я бы прыгал от радости и хлопал в ладоши, если бы PL/SQL явно был бы просто специфическим форком Ada,
и развивался примерно параллельно языку прародителю, предоставляя примерно эквивалентные возможности.

Кажется, после появления типов-объектов в 8-ке как словарных сущностей, такого рода надежда превратилась в "просто фантастику".

((;
27 июн 20, 13:44    [22158203]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 62522
Блог
booby
Какие именно "многие задачи" вы хотели бы на ней решать

Этот вопрос сводится к вопросу "какие задачи плохо решает PL/SQL". А таковых довольно много.

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

Очевидным путём оптимизации было бы перенести хранение этих временных сырых данных в оперативку. Да, конечно, гигабайт-другой на них бы ушёл, но также ушла бы нагрузка с PGA, буферного кэша итп, и общий прирост производительности был бы просто офигенным. Мне удалось довольно просто внедрить в существующую систему API для доступа к временным данным - уровня "дай мне запись по id", "поменяй временные данные по id" - а вот дальше начались танцы. Если коротко, в рамках одной сессии всё великолепно работало, но как только требовался обмен данными между сессиями - любая реализация уходила в унитаз. Оказывалось, что мать-мать-мать вставить в таблицу в одной сессии и прочитать из другой - кроет любое java-взаимодействие как слон комара. И не потому, что java такая плохая - вне базы тот же код отлично и быстро работал - а потому что мать-мать-мать так работает java внутри базы. И попытки из базы стучаться к движку снаружи базы - тоже мать-мать-мать тормозят как будто их делают сотрудники Почты России. И это я уже не говорю о том, что кучу кода приходилось писать самому вместо того, чтобы пользоваться доступными готовыми решениями, просто потому, что уже хрен отыщешь актуальные готовые решения, которые компилировались бы в java 4.

Ну а где ещё пригодилась бы хорошо работающая Java... во-первых, везде, где хочется уровня обобщения и абстракции большего, чем позволяет PL/SQL. Надеюсь, не обязательно перечислять миллион таких мест. Во-вторых же - можно было бы подумать над выполнением внутри базы многого из того, чем яваголовые грузят application server. Фактически ушли бы многие причины, подталкивающие к выбору трёхзвенной архитектуры.
27 июн 20, 17:44    [22158286]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47616
Даже просто размер строки VARCHAR2 в 32 килобайта - это уже ограничение для современного бизнеса.
Оно - то понятно что в нормализованой модели редко такое бывает. Но данные - бывает часто заходят
в полу-сыром виде. И это не только XML/Json. И похитрее форматы бывают. Теже офисные документы.

Да конечно можно вынести это в application. Но если тема топика - улучшение PL-машины то у нас уже
есть поинты куда ее хотелось-бы улучшать. Языковые возможности. Ada. Или может лучше Oberon?

И просто тот сценарий который описал softwarer.

Ну и мультипоточка. Сетевые сокеты. I/O.
27 июн 20, 18:04    [22158292]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
semirax
Member

Откуда:
Сообщений: 451
Arists,

Похвально, что вы озаботились увеличением эффективности кода. Я тоже в свое время об этом думал и пришел к следующим советам, которые могут оказаться полезными.

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

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

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

4) как правило, лучше иметь стандарт кодирования и жестко его придерживаться. Стандарт может быть любым, но он должен быть.
Мои рекомендации стандартные и идут еще от Кайта
а) отличать ключевые слова и названия системных пакетов от всего остального - например, все системное всегда писать с большой буквы (SELECT)
б) отличать названия локальных, глобальных переменных и параметров функций по префиксу ("g" - глобальная переменная пакета, "a" - параметр процедуры/функции, "l" - локальная переменная).
в) договориться об отступах при переходе к вложенным блокам, например делать +2 пробела при переходе к следующему уровню вложенности
д) договориться везде в названиях типов использовать не явное указание типа в духе VARCHAR2(100), а ссылаться на таблицу вида имя_таблицы.поле%TYPE. Когда таблиц становится 200-300, очень помогает.

Сообщение было отредактировано: 27 июн 20, 19:34
27 июн 20, 19:31    [22158321]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
softwarer,

Чтобы содержательно комментировать тот сыр-бор, который вы описали, надо, конечно,
и видеть весь контекст, и понимать, на какое историческое время он накладывается.

Ваше описание я понял так: грузится "большой набор сырых данных", который затем последовательно или параллельно
обрабатывается одновременно в нескольких сеансах, в условиях общей высокой нагрузки на систему, превышающий ее возможности, в первую очередь, по вводу-выводу.
В былые времена, для описываемых вами ситуаций, рекомендовали приделывать фронт с какой-нибудь Berkeley DB,
в современных версиях для чего-то похожего можно прилаживать Inmemory Tables

С точки зрения "былых времен" можно с разных сторон заходить на решение проблемы, из которых на первое место,
вообще до всего остального, я бы категорически, и преодолевая истерики по части "и так медленно работает", поставил бы
уменьшение степени параллельности обработки.
До разборок сорта - ява ли она, где и каким боком хороша, или как добавить память в сервер.

Касательно слепящей силы явы сказать можно следующее:
Скорее всего, почти наверно, вы ухудшили ситуацию, ввязав в это дело яву, но винить её я не стал бы....
Так, если система задохлась от log file sync, например, - ява никаким боком, ни при какой серверной реализации,
помочь не сможет, просто потому, что свою долю процессорного времени не получит.
К таким историям сначала должны подключаться администраторы, просто потому что "плохая программа"
уже есть и как-то плохо работает.

Что касается "вынести работу в память" - сам по себе заход может оказаться и разумным и правильным,
при правильном подходе, реализации и удобном для этого случае.
Но прежде всего надо понимать, что с точки зрения вызова в текущем сеансе - любой код pl/sql - однопоточный.
Все возможности по взаимодействию сеансов лежат либо постоянных таблицах, либо очередях, либо в dbms_pipe + dbms_alert.
А вся "многопоточка" - в джобах. В общем, все.
Если путем работы с памятью удается "кешированием" решить проблемы ввода-вывода, да еще и сгруппировать запись, хотя бы с forall - система может задышать и без администратора.

Пусть теперь, внезапно, сеансу потребовалась ява.
Тогда в сеанс будут загружена персональная, имени этого сеанса ява-машина,
которой будет предоставлен один процессор.
Для загруженных многопользовательских систем с дефицитом оперативной памяти - это слишком очевидное зло, чтобы вообще начинать о нем мечтать - этих ява-машин загруженных будет столько, сколько открыто сеансов.

Единственное оправдание, это когда в стандартное библиотеках у явы есть некий внезапно понадобившийся функционал,
повторить который без помощника - две недели, с помощником - полгода, а написать оболочку к нему и вызов из pl/sql - пять минут.
Такого рода истории почти всегда и почти автоматически решаются однозначно, но процент таких "потребностей",
до xml-безумия, был, с моей точки зрения, ничтожно мал.

2 mayton
"многопоточка" и однопоточное исполнение pl/sql в сеансе - это "интересно". :))

"лучше Oberon" - а) его нет, это "история", причем промышленно не состоявшаяся.

Ada не просто исторический прототип PL/SQL сорта взяли плохую аду, улучшили/облегчили и получился хороший PL/SQL.
Ada жива, развивается, исторически была первым примером подхода к обобщенному программированию,
и первой попытки реализации "стандартной библиотеки",
а с 2012 года, является первым примером языка с работающими контрактами.
Атрибуты типа у неё были всегда, задолго до мучительного изобретения слов сорта traits и некоторых следом новых.
Просто - атрибут типа. Он у типа есть. И новые слова - не нужны.
Это печалит, но я уже не на столько молод, чтобы этому печалиться.

Сообщение было отредактировано: 27 июн 20, 23:27
27 июн 20, 23:28    [22158433]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 47616
booby

2 mayton
"многопоточка" и однопоточное исполнение pl/sql в сеансе - это "интересно". :))

Если вы мучались с использовали dbms_job/scheduler то вы должны меня понять.

Ada не просто исторический прототип PL/SQL сорта взяли плохую аду, улучшили/облегчили и получился хороший PL/SQL.
Ada жива, развивается, исторически была первым примером подхода к обобщенному программированию,
и первой попытки реализации "стандартной библиотеки",
а с 2012 года, является первым примером языка с работающими контрактами.
Атрибуты типа у неё были всегда, задолго до мучительного изобретения слов сорта traits и некоторых следом новых.
Просто - атрибут типа. Он у типа есть. И новые слова - не нужны.

Ладно к чорту Оберон. И не сильно он мне был нужен.

А не просвятите, где сейчас применяется Ада? Кроме общеобразовательных сфер конешно.
Просто для меня это экзотика.
27 июн 20, 23:37    [22158440]     Ответить | Цитировать Сообщить модератору
 Re: Улучшение кода PL\SQL  [new]
booby
Member

Откуда:
Сообщений: 1974
mayton

А не просвятите, где сейчас применяется Ада? Кроме общеобразовательных сфер конешно.
Просто для меня это экзотика.

В штатах - большинство авионики, и кое-какой космос.
В Европе - железные дороги, главным образом.
В общем, почти целиком ушла в программирование контроллеров и прочий околопромышленный софт.
Кто-то, французы, кажется, какой-то софт для банкоматов на ней пишут.
Ада-люди, кроме США, живут во Франции, Германии, Голландии. Вроде в Англии каки-то сумасшедши тоже есть.

У нас почти загибла.
Когда-то летала на самолетах Бериева.
Не знаю, сейчас на БЕ-200 выкорчевали её или всё еще летает...
28 июн 20, 00:07    [22158444]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить