Pull to refresh
17
0
Дмитрий @StrangerInTheKy

PL/SQL разработчик

Send message
Интересно, конечно, но эта функция может понадобиться, только если у вас полный хаос в процессах разработки и тестирования. При нормальной организации процесса и использовании систем контроля версий сам факт попадания на продакшен кода, который не компилируется, практически исключен.
2. Попробовал. По ctrl+P действительно появляется, но работает очень неудобно. Напишу баг-репорт.

6. Да, посмотрел, действительно есть. Не понравилось, что там идет всё вперемешку. Столбцы, констрейнты, индексы, у разных типов вдобавок разные иконки, всё сливается. Может, лучше сделать подкатегории? Столбцы показывать сразу, как только кликаешь на треугольник у имени таблицы, а индексы, констрейнты и прочее показывать отдельными подкатегориями, свернутыми по умолчанию?

7. Отправил.
Это круто, если все это есть. А в какой версии появились Live Template, Refactoring и Inspections? Как я уже говорил, последняя версия, которой я пользовался — это та, которая была доступна для установки в декабре 2012-го. Тогда их то ли не было, то ли они были не на виду.
1. Да, что-то такое слышал. На самом деле, у меня даже была лицензия на IDEA, оформленная на меня (подарок на ДР).

2. Да, проверил еще раз, всё работает. Просто довольно долгое время пользовался Oracle SQL Developer, где эта функция не работала, и отвык. Видимо, даже не попробовал. А вот подсказка по аргументам функций как у PL/SQL Developer есть? Я только не помню, где я видел это — то ли в PL/SQL Developer, то ли вообще в Lazarus. Там была, помнится, совершенно очаровательная вещь: когда пишешь вызов функции и курсор стоит внутри скобок, ниже отображается окно с подсказками, в котором есть список названий аргументов и их типов, и вдобавок жирным выделен агрумент, на котором курсор стоит сейчас. Если у вас такого нет, напишу реквест. Пока же все IDE прячут подсказки, когда имя функции уже написано, и курсор стоит в скобках.

3. Попробовал. Выглядит круто, спасибо, то что надо.

4. Практически не мешает с тех пор, как я обнаружил, что можно выделять текст мышкой, удерживая Alt. Ну может и напишу.

5. Спасибо, надо попробовать.

6. Ох, ну и запросы у вас ;) Это материал на целую статью. Кроме того, тут в комментариях уже много написано всяких советов, нужно их сначала переварить. Из того, что сразу приходит в голову, хотелось бы видеть в списках объектов внутри схемы ДБ линки (вчера как раз искал их и не нашел), публичные синонимы, индексы и триггеры.

7. Это был шуточный намек на то, что статья — моя частная инициатива, никак не связанная с JetBrains (уж не знаю, насколько удачный). Живу я от вас далековато (в одной маленькой, но гордой западноевропейской стране), но если будете у нас на колыме — милости просим, пиво тут хорошее.
Тогда получается, что кому больше приглянулось, скажем визуально, тот то и выберет?
Ну в общем да, если брать только список доступных функций, то отличия не сказать что очень большие, разница больше касается того, как все выглядит и насколько удобно пользоваться, а это довольно индивидуальные вещи.
Но есть мелкие удобства в DataGrip, которых нет в DataBase plugin.
А можно пару примеров? А то я сразу в IDEA начал работать, DataGrip отдельно не пробовал.
И Вы считаете, что этот порог ниже, чем у Mavo?
Это порог для чтения моего туториала, а не для освоения апекса. А далее в моем туториале, между прочим, написано следующее:
… по своему опыту я могу сказать, что человек, не читавший никаких туториалов вообще, самостоятельно найдет, как создать приложение, добавить страницу, поместить на нее отчет и так далее
В апексе можно создавать таблицы и страницы для записи в них данных и отображения отчетов, не изучая SQL. Там действительно интуитивно-понятный интерфейс, есть графический построитель запросов и так далее. Просто мне неинтересно писать туториал по очевидным вещам для тех, кто ничего не знает, мне интересно писать про более крутые фичи для тех, кто знает хотя бы SQL.

Прочитав Вашу статью — я понятия не имею как это сделать на APEX. Но если «Mavo — жалкое подобие апекса» — то, по логике, любая задача легко решаемая на Mavo может быть также или еще проще решена на APEX. Или нет?
Как я уже и сказал выше, в моем туториале нет никаких очевидных вещей. Когда я начинал изучать апекс, я только немного знал SQL, не имел никакого опыта работы с ораклом, и не знал ничего вообще о HTML, CSS и javascript. И книг и туториалов тоже не читал. Мне этого вполне хватило, чтобы зайти на apex.oracle.com, и самостоятельно разобраться, как создать таблицы, страницы, поля для ввода и так далее.

Вообще, странно, что Вы сравниваете Mavo именно с APEX.
Что знаю, с тем и сравниваю. В статье что написано? Вот что:
Так вот, почему бы нам с вами вместе не разработать такое приложение? Назовём его… (барабанная дробь!) «Карточки». Это будет полноценное CRUD-приложение для изучения иностранного языка с помощью карточек
Так вот, апекс создан именно для разработки CRUD-приложений, и на этом поле с ним мало кто может тягаться.
Гляньте упомянутый выше Oracle APEX (и мои публикации на Хабре тоже как раз о нем). Иерархия требований к скиллам примерно следующая: SQL — PL/SQL — Javascript — HTML/CSS (чем раньше написан скилл, тем раньше и больше он понадобится, но на базовом уровне можно вообще ничего не знать).
В этом и трагедия: HTML и CSS — база и фундаментальная основа веб. Не знать их (или сознательно отказываться), на мой взгляд, — преступление.
Да ну? А я думал, база — это TCP/IP и HTTP!
Не знать их (или сознательно отказываться), на мой взгляд, — преступление.
Это громкие слова, за которыми ничего не стоит. Что значит «преступление»? Меня посадят? А вот примерно 7 миллиардов человек не знают HTML и CSS — их тоже посадят? Или что сделают с нами всеми?
Не слышал, чтобы Mavo опирался на Oracle APEX, чтобы быть его «жалким подобием».
А ему и не надо опираться. Вы в статье упираете на то, что у Mavo низкий порог входа и широкие возможности. У APEX примерно та же область применения, но порог входа ниже, а возможности шире. Именно поэтому Mavo — жалкое подобие апекса.
Если Вам интересно, о каких исследованиях и системах идёт речь
Совершенно неинтересно. Но я все-таки глянул по диагонали — так себе исследование. Авторы придумали простенький недоязык с десятком (от силы) команд, а потом проверили, смогут ли выучить этот язык люди, которые уже выучили более сложные вещи. Результат — смогут! Называть такое наукой я бы постеснялся.
Ну и потом. В абстракте авторы заявляют:
We show that it lets authorscreate a more powerful set of applications than they couldpreviously, while adding little additional complexity to theauthoring process.
Но при этом не дают (или я пропустил?) никаких методик сравнения мощности приложений и дополнительной сложности инструментов. А без этого как-то банально получается: мы дали людям более сложный инструмент, и они с его помощью сделали более функциональное приложение. Ну как бы да, именно так и должно быть, было бы наоборот — это был бы полный провал.
Mavo — это новый подход к разработке интерактивных веб-приложений только за счёт написания HTML и CSS, без необходимости написания кода на языке JavaScript и разворачивания собственного сервера.
Это не новый подход, это жалкое подобие Oracle APEX. В апексе можно делать все то же самое и даже намного больше, но при этом не надо знать даже HTML и CSS.

ПЦ текст. «Дорогие граждане России и Китая, мы вам отключим доступ к сети, пока вы не свергнете ваши авторитарные правительства и не установите демократию. Как сделаете, приходите, мы подумаем.»
С такими друзьями и врагов не надо.


P. S. Если я понял текст неправильно, объясните, как правильно.

Справедливости ради, это не пирожки. У пирожка не должно быть рифм, другой размер и число слогов. Там это всё жестко фиксировано.

Не моё (пирожок):


ваш код сегодняшний коллега
напоминает даунхилл
среди деревьев и говнища
велосипед и костыли

мы же не базу мертвецов строим, ведь?
Если у вас вообще как-то фигурирует слово «смерть» в ТЗ, то да, мы строим базу мертвецов. Например, БД ЗАГСа будет такой базой. Вы же не думаете, что в момент смерти данные по человеку тупо удаляются из БД?

полей нет, зато есть таблицы ))
например для увольнения есть таблица приказов/заявлений
для смерти — другая таблица.
Целую таблицу под смерти? Слишком дофига. Для разовых событий (типа рождения и смерти) вполне достаточно просто одного поля с соответсвующим событием. А вот под документальное сопровождение этих процессов уже можно нагородить таблиц (например, человек может быть признан мертвым, потом найтись живым, а то и несколько раз так, но в итоге рано или поздно он умрет окончательно, и на каждый такой случай будет решение уполномоченного органа — полиции, больницы, суда и т. д., а на каждое решение — запись в базе).

В "Сумме Технологии" (1964 г.) и нескольких пьесах. И вроде бы говорят, что даже Лем не был первым. А "Футурологический конгресс" — это немного про другое.

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


А дальше вода кончается, и начинаются перлы.

Как мы уже ранее говорили, от назначения базы данных зависит, какие методы использовать при моделировании.
Методы моделирования совершенно не зависят от назначения БД.
Если мы проектируем базу данных для оперативной обработки записей (OLTP), иными словами для их создания, редактирования и удаления, то используем моделирование транзакций. Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование.
Как сие понимать? База может быть либо OLTP, либо реляционной??? Конечно же нет, база очень легко может быть и OLTP, и реляционной одновременно. OLTP обычно противопоставляется OLAP'у, но тут и выбирать особо нечего: если знать, что каждая из аббревиатур означает, перепутать их друг с другом практически невозможно.

используем моделирование транзакций
Моделирование транзакций — это что за зверь? Что там моделировать??? За 12 лет в IT ни разу не слышал ничего подобного.

Во время моделирования строятся концептуальные (CDM), физические (PDM) и логические (LDM) модели данных.
Эти модели строятся разве что диванными теоретиками. На практике обычной ER-диаграммы более чем достаточно.

Если же сущность ведет собственную жизнь, имеет атрибуты, которые описывают ее поведение и ее вид, а также отношения с другими объектами, то смело можно использовать не только подтип, но и супертип ( родительская сущность).
Совершенно непонятно, о каких БД вы говорите в статье. Вроде бы в одних местах говорите не только о реляционных, но зачем-то в других местах употребляете термины, относящиеся только к реляционной модели, не уточняя, что имеете в виду именно ее, а где-то говорите о вещах, к реляционной модели не относящихся вообще. Лучшего способа запутать читателя не придумаешь. Этот кусок, например, — он о чем вообще?

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

Если только бизнес-ключ не уникален
Если ключ не уникален, то он не ключ. Ваш Кэп.

Существует пять нормальных форм, которым нужно следовать.
Во-первых, не пять (но тут как считать, и вообще, это неважно), во-вторых, не «нужно», а «можно», и в большинстве случаев работает правило «бери третью — не ошибешься».

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

В общем, статья — отличная антиреклама для курсов. Ни за что никому не порекомендую курсы, которые таким образом рекламируются.

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

Мой ребенок примерно в три года начал демонстрировать признаки наличия у него теории ума. Он не любит спать днем, и вообще спать (да и кто любит в его возрасте). Когда он просыпается, он лежит у себя в комнате и кричит "я проснулся". Иногда он начинает кричать "я проснулся" до того, как поспит (мы ему отвечаем на это — ты еще не заснул). Но это пока просто хитрость. А однажды он перешел на новый уровень: я укладываю его спать, выхожу из комнаты, а он буквально через минуту кричит: "Мама, я проснулся". То есть он понимает, что папа его только уложил и точно знает, что он еще не поспал, а вот мама была все это время далеко и может не знать. Папу не обманешь, а вот с мамой можно попытать счастья.
Точно не знаю, в каком возрасте это было, но ему сейчас чуть больше трех с половиной, а было это около полугода назад, если не больше.
Кажется, это оно.

Мысль про сговор очень разумная! Не совсем в такой формулировке, но я тоже подозревала, что понимание того, что взрослые между собой обо всем договариваются, может порядочно зашумлять результаты.

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

Меня, собсна, интересовало, как вы будете интерпретировать ответ на этот вопрос. Какую информацию о кандидате можно извлечь из его ответа на вопрос "что такое fork", я более-менее представляю. А вот какую из ответа про книгу — не представляю совершенно.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity