Как понял из ответа, ИИ, может быть, и поможет, но только если достаточно долго пинать его ногами (подобные мысли я встречал ранее в Интернете).
Мой личный опыт как раз говоит обратное. Скорее - пошло дело вкось, хоть всё дело брось. Пытаешься поправить косяки ИИ вторым промтом, а он ещё больше увязает в неверном понимании. Обычно я бросаю начатый чат, чтобы сменить контекст и открываю новый. Вот вчерашний пример: засунул в ИИ legacy хранимую процедуру и попросил переписать её в виде аккессора для модели. ИИ это сделал. Но сделал лоб в лоб, сохранив неоптимальную легаси-логику и не применив современных решений. Я даже не стал пинать в этом чате ИИ, просто скопировал его код в другой чат и попросил оптимизировать. Вот тогда вышло более-менее сносно.
Кстати, урезенная версия chatgpt есть в свободном бесплатном доступе. Один чат, без сохранения истории, ограничения по количество токенов. Можете попробовать.
На это уйдёт уйма времени. Каждый блок нужно будет выверить, протестировать, как эти блоки будут себя вести вместе, с ошибочными данными, злонамеренными данными, граничными случаями. Ежедневно пользуюсь GPT, он постоянно выдаёт legacy решения, не знаком с актуальными технологиями, иногда очень убедительно врёт. Так что за ним глаз да глаз.
Ну вот видите, я как в воду глядел про близорукость. У меня же дальнозоркость с измальства, а с годами развилась та самая пресбиопия. Это невозможность менять фокус в прежних пределах. Так что такие штуки, как штангены с огромными циферками для меня просто незаменимая вещь. Хоть и с нониуса считывать умею.
И да, @ksbesабсолютно прав, что развивающаяся дальнозоркость не компенсирует близорукость. Так что здесь будет где развернуться окулисту, чтобы придумать стратегию корректировки зрения. Ну это если к тому времени, какая-нибудь глаукома не убьёт зрительный нерв или стекловидное тело не подвергнется деструкции.
Либо Вам «повезло» с близорукостью, либо на шестом десятке вам всё-таки начнут нравится электронные штангены с большими циферками. Пресбиопию никто не отменял.
(Зато не нужно ещё один прибор на зарядку ставить).
О, как мне это знакомо! Если я ошибусь в налоговой декларации, то штраф прилетит быстро и точно. А мне тут регистраторы в росреестре с моими правами на недвижимость наошибались. Так я замучился бегать и умолять ошибку исправить.
То, что можно сделать с помощью .sh, .bat, make-файлов, не имеет никакой графической альтернативы.
Имеет. Задача пользователя будет решена без использования сценариев, только за счёт графической альтернативы.
Это несёт некоторые временные издержки. Но дальше уже пользователь сам для себя решает, что ему выгоднее, собирать задания в очереди с помощью GUI или освоить программирование в шелл. Кстати, не обязательно в шелл. Можно ведь скрипт на php написать, который также будет дёргать нужные утилиты.
По итогу я могу скрипт не писать. Я могу использовать только MKVToolNix. Просто лично для меня такой способ наиболее быстрый. Я попросил GUI сделать для меня прототип команды и запихнул его в цикл. Я сэкономил время на написании команды (её даже набирать долго, учитывая длинные названия файлов) и на гуглении ключей. А также сэкономил время на создании очереди заданий в GUI. Но по итогу, если пользователь не умеет писать шелл-скрипты, этот навык для него необязателен.
То, что можно сделать с помощью .sh, .bat, make-файлов, не имеет никакой графической альтернативы.
Разработчики всяких TUI/GUI обёрток над консольными утилитами с вами не согласны. Вы правы, что главный плюс CLI в возможности автоматизации. Но когда мне нужно обработать 36 серий сериала, я не хватаю vim и не пишу скрипт с нуля. А беру MKVToolNix, мержу первый файл, потом импортирую команду. И уже затем пишут цикл в .sh, .bat, .cmd. Получается значительно быстрее, чем читать справку по командам и ключам.
Выучить десяток команд для обычного человека — пара пустяков.
Зачем? Чтобы что? Ну вот надо было мне гибернацию наладить на своём ноуте под Ubuntu. Для этого надо было реорганизовать swap. Ну справился я с этой задачей в консоли. Гибернация работает. Год работает, два работает… Думаете, я помню утилиты и их команды с ключами, которыми пользовался? Помнится только то, чем пользуешься постоянно. А обычные люди не пользуются шеллом, обычные люди пользуются каким-либо приложением. Так что вся работа в командной строке будет сводиться к запуску приложения.
Насколько я помню, там можно было накладывать графический экран на текстовый, совмещая текстовый и графический режимы.
Да, можно. Только для этого нужна была библиотека KeyGP, разрабатывавшаяся в Зеленограде, в том же предприятии, где делали ДВК. Эта библиотека была платная и имела хитроумную привязку к диску, т.е. просто так не скопируешь. Причём эта привязка в первых версиях слетала при дефрагментации диска. Потом этот баг пофиксили.
И что самое удивительное, в этом режиме даже работал скроллинг. Можно было вывести строку в stdout и весь экран вместе с текстом и графикой скроллился вверх. Такого я больше нигде не видел. Либо текстовый режим, либо графический.
и пробежаться глазами по ключам - они типовые, зачастую.
Зачастую они противоречивые и не логичные. Т.к. не было никого, кто бы координировал разработку утилит командной строки и применял хоть какие-либо стандарты. Совершенно непонятно, почему для отметки схемы в команде pg_dump используется ключ -n, или почему у pg_dump есть ключ -f, а у pg_restore его нет.
Если что, я в командной строке сидел ещё во времена ДВК-3. Но как только перестаёшь постоянно выполнять некие повторяющиеся действия, так из головы постепенно улетучиваются ключи, опции, и даже имена самих команд.
Да даже постоянно повторять одни и те же действия, с риском опечаток, и необходимостью совершать дополнительные действия, может быть утомительно.
Простой пример: мне нужно перейти в некий каталог (какой не помню), и что-то в нём сделать. Для начала придётся десяток раз вызвать ls(dir)/cd. mc или Norton Commander куда как приятнее. Особенно если выучишь хоткеи.
CLI, как и игра на пианино, требует постоянной практики.
Концептуально это то же самое, что и GUI, только с худшим качеством картинки.
Вот тут готов поспорить. Битовая матрица символа считывалась на отлично даже на древних мониторах размером 25 строк на 80 символов.
В своё время разрабатывал прекрасные TUI для ДВК-3.
Плюсом у буковок можно поменять цвет, если монитор не монохромный, и подрисовать им фон. Таким образом можно выделять хот-кеи и активные пункты меню. И даже рисовать тени у открытых окон, имитируя Z-order.
Скрытый текст
Естественно, всякие рюшечки, в виде буковок различного размера, и всякие пиктограммки не нарисуешь.
Но как по мне, TUI не заслуженно забыт и оставлен в сторонке. Ничто не мешает писать утилиты командной строки таким образом, чтобы они не только получали параметры, опции, команды, но и вполне себе обладали интерфейсом пользователя.
Я бы ещё добавил, что эффективная работа в терминале требует навыка слепого набора текста, без которого в терминале работать становится несколько проблематично. Если оператор медленно набирает двумя пальцами, уткнувшись взглядом в клавиатуру, то крайне велика вероятность пропустить опечатку, с последующим разгадыванием квеста: почему же не сработала команда?
Как-то автор перескочил через TUI. UI не обязательно может быть графическим. Он вполне может быть себе текстовым. Тот же небезызвестный Norton Commander тому пример. А уж сколько софта было написано на текстовом фреймворке TurboVision…
Они не только не умеют считать буквы, они действительно не знают, из каких букв состоит слово. Попросил LLM объяснить, как запомнить ключ -n для указания схемы утилите pg_dump.
Прошу искренне извинить. Из контекста на Вас подумалось.
Потому что это первое на что смотришь в плане запроса
Так я ведь с этим и не спорю. Все знают, что seq scan на больших объёмах данных это нехорошо.
Ну это лично Ваше восприятие
Ну да. Это моё восприятие. Мне показалось, что автор имеет ввиду, что для поиска соподчинённых данных нужно всего лишь добавить ключевые поля. Даже своё восприятие аргументировал. А тут мне минусы лепят и рассказывают очевидные вещи о пользе индексирования. Я уж весь мозг изломал, что же я такого крамольного написал.
Нет, так как фраза "к получению всех владельцев домашнего питомца" уже подразумевает, что у домашнего питомца могло быть несколько владельцев.
Абсолютно согласен. Просто было лениво рисовать pivot таблицу. Но рад, что Вы наконец-то внимательно прочитали текст сообщения и даже потратили время на аргументацию. Жаль, что минус не отозвали.
Индексы позволяют избежать сканирования таблиц.
Каким образом это утверждение соотносится с утверждением автора:
При работе с реляционной базой данных можно перейти от получения всех домашних питомцев человека к получению всех владельцев домашнего питомца, добавив в таблицы один-два индекса.
Никакие внешние ключи сюда не прикрутите, хотя консистентность можно контролировать триггерами.
Да ладно?
CREATE TABLE owners_to_pets (
Id integer NOT NULL,
Valid daterange NOT NULL,
own_id int NOT NULL,
pet_id int NOT NULL,
CONSTRAINT owners_to_pets_PK_idx
EXCLUDE USING GIST (pet_id WITH =, Valid WITH &&),
-- в конкретный период у питомца может быть только один владелец
-- Внешние ключи
CONSTRAINT fk_owners
FOREIGN KEY (own_id)
REFERENCES owners(Id)
ON DELETE CASCADE,
CONSTRAINT fk_pets
FOREIGN KEY (pet_id)
REFERENCES pets(Id)
ON DELETE CASCADE
);
Держите внешние ключи. Но будет и без них работать, как я и написал выше. Просто просторечно поля вида own_id и pet_id называют внешними ключами, хотя внешние ключи могут быть и не построены.
Выборка всех владельцев питомца возможна по индексу owners_to_pets_PK_idx без сканирования таблицы owners_to_pets. А вот для того, чтобы наоборот, найти всех питомцов владельца на конкретный момент времени без сканирования таблицы, потребуется еще один индекс …
Я откровенно не понимаю, почему Вы прицепились к сканированию таблицы?
Поясняю, даже без единого индекса, СУБД найдёт искомые записи, уж как оно будет это делать, эффективно или нет, неважно. НАЙДЁТ!
А вот если выкинуть поля own_id и pet_id — НЕ НАЙДЁТ!
В оригинале не идёт речь о том, что можно получить всех владельцев домашнего питомца без использования seq scan. А о том, что их можно получить, добавив...
Вот на мой взгляд, добавив ключевые поля. А никак не индексы.
Внешние ключи никак не влияют на производительность выборки данных
Я где-то утверждал обратное?
Смотрите внимательно: есть таблица, содержащая виды (типы) домашних питомцев. Всё верно? В оригинале:
можно перейти от получения всех домашних питомцев человека
Есть таблица владельцев домашних животных. В оригинале:
перейти ... к получению всех владельцев домашнего питомца
Таблица: Владельцы Таблица: Домашние Животные
+----+------------+ +----+------------+------------+
| ID | Имя | | ID | Вид | Владелец_ID|
+----+------------+ +----+------------+------------+
| 1 | Иван | | 1 | Кошка | 1 |
| 2 | Анна | | 2 | Собака | 1 |
| 3 | Ольга | | 3 | Хомяк | 2 |
| 4 | Павел | | 4 | Попугай | 3 |
+----+------------+ +----+------------+------------+
Получить владельцев домашних питомцев можно создав реляцию между этими двумя таблицами. И индексы здесь не при чём.
Нам нужно ключевое поле, на которое можно ссылаться и индекс по нему может быть вообще не построен. И внешний ключ. Строго говоря, внешний ключ тоже не обязателен. Но для целей самодокументирования и обеспечения ссылочной целостности — крайне желателен.
Вот и получается, что Вы не поняли о чём идёт речь, но минус влепили.
При работе с реляционной базой данных можно перейти от получения всех домашних питомцев человека к получению всех владельцев домашнего питомца, добавив в таблицы один-два индекса.
Мой личный опыт как раз говоит обратное. Скорее - пошло дело вкось, хоть всё дело брось. Пытаешься поправить косяки ИИ вторым промтом, а он ещё больше увязает в неверном понимании. Обычно я бросаю начатый чат, чтобы сменить контекст и открываю новый. Вот вчерашний пример: засунул в ИИ legacy хранимую процедуру и попросил переписать её в виде аккессора для модели. ИИ это сделал. Но сделал лоб в лоб, сохранив неоптимальную легаси-логику и не применив современных решений. Я даже не стал пинать в этом чате ИИ, просто скопировал его код в другой чат и попросил оптимизировать. Вот тогда вышло более-менее сносно.
Кстати, урезенная версия chatgpt есть в свободном бесплатном доступе. Один чат, без сохранения истории, ограничения по количество токенов. Можете попробовать.
На это уйдёт уйма времени. Каждый блок нужно будет выверить, протестировать, как эти блоки будут себя вести вместе, с ошибочными данными, злонамеренными данными, граничными случаями. Ежедневно пользуюсь GPT, он постоянно выдаёт legacy решения, не знаком с актуальными технологиями, иногда очень убедительно врёт. Так что за ним глаз да глаз.
Ну вот видите, я как в воду глядел про близорукость. У меня же дальнозоркость с измальства, а с годами развилась та самая пресбиопия. Это невозможность менять фокус в прежних пределах. Так что такие штуки, как штангены с огромными циферками для меня просто незаменимая вещь. Хоть и с нониуса считывать умею.
И да, @ksbesабсолютно прав, что развивающаяся дальнозоркость не компенсирует близорукость. Так что здесь будет где развернуться окулисту, чтобы придумать стратегию корректировки зрения. Ну это если к тому времени, какая-нибудь глаукома не убьёт зрительный нерв или стекловидное тело не подвергнется деструкции.
Либо Вам «повезло» с близорукостью, либо на шестом десятке вам всё-таки начнут нравится электронные штангены с большими циферками. Пресбиопию никто не отменял.
Зато нужно очки с собою таскать.
О, как мне это знакомо! Если я ошибусь в налоговой декларации, то штраф прилетит быстро и точно. А мне тут регистраторы в росреестре с моими правами на недвижимость наошибались. Так я замучился бегать и умолять ошибку исправить.
Я с этим не спорю. Я не согласен с утверждением:
Имеет. Задача пользователя будет решена без использования сценариев, только за счёт графической альтернативы.
Это несёт некоторые временные издержки. Но дальше уже пользователь сам для себя решает, что ему выгоднее, собирать задания в очереди с помощью GUI или освоить программирование в шелл. Кстати, не обязательно в шелл. Можно ведь скрипт на php написать, который также будет дёргать нужные утилиты.
По итогу я могу скрипт не писать. Я могу использовать только MKVToolNix. Просто лично для меня такой способ наиболее быстрый. Я попросил GUI сделать для меня прототип команды и запихнул его в цикл. Я сэкономил время на написании команды (её даже набирать долго, учитывая длинные названия файлов) и на гуглении ключей. А также сэкономил время на создании очереди заданий в GUI. Но по итогу, если пользователь не умеет писать шелл-скрипты, этот навык для него необязателен.
Разработчики всяких TUI/GUI обёрток над консольными утилитами с вами не согласны. Вы правы, что главный плюс CLI в возможности автоматизации. Но когда мне нужно обработать 36 серий сериала, я не хватаю vim и не пишу скрипт с нуля. А беру MKVToolNix, мержу первый файл, потом импортирую команду. И уже затем пишут цикл в .sh, .bat, .cmd. Получается значительно быстрее, чем читать справку по командам и ключам.
Зачем? Чтобы что? Ну вот надо было мне гибернацию наладить на своём ноуте под Ubuntu. Для этого надо было реорганизовать swap. Ну справился я с этой задачей в консоли. Гибернация работает. Год работает, два работает… Думаете, я помню утилиты и их команды с ключами, которыми пользовался? Помнится только то, чем пользуешься постоянно. А обычные люди не пользуются шеллом, обычные люди пользуются каким-либо приложением. Так что вся работа в командной строке будет сводиться к запуску приложения.
Да, можно. Только для этого нужна была библиотека KeyGP, разрабатывавшаяся в Зеленограде, в том же предприятии, где делали ДВК. Эта библиотека была платная и имела хитроумную привязку к диску, т.е. просто так не скопируешь. Причём эта привязка в первых версиях слетала при дефрагментации диска. Потом этот баг пофиксили.
И что самое удивительное, в этом режиме даже работал скроллинг. Можно было вывести строку в stdout и весь экран вместе с текстом и графикой скроллился вверх. Такого я больше нигде не видел. Либо текстовый режим, либо графический.
Зачастую они противоречивые и не логичные. Т.к. не было никого, кто бы координировал разработку утилит командной строки и применял хоть какие-либо стандарты. Совершенно непонятно, почему для отметки схемы в команде pg_dump используется ключ -n, или почему у pg_dump есть ключ -f, а у pg_restore его нет.
Если что, я в командной строке сидел ещё во времена ДВК-3. Но как только перестаёшь постоянно выполнять некие повторяющиеся действия, так из головы постепенно улетучиваются ключи, опции, и даже имена самих команд.
Да даже постоянно повторять одни и те же действия, с риском опечаток, и необходимостью совершать дополнительные действия, может быть утомительно.
Простой пример: мне нужно перейти в некий каталог (какой не помню), и что-то в нём сделать. Для начала придётся десяток раз вызвать ls(dir)/cd. mc или Norton Commander куда как приятнее. Особенно если выучишь хоткеи.
CLI, как и игра на пианино, требует постоянной практики.
Вот тут готов поспорить. Битовая матрица символа считывалась на отлично даже на древних мониторах размером 25 строк на 80 символов.
В своё время разрабатывал прекрасные TUI для ДВК-3.
Плюсом у буковок можно поменять цвет, если монитор не монохромный, и подрисовать им фон. Таким образом можно выделять хот-кеи и активные пункты меню. И даже рисовать тени у открытых окон, имитируя Z-order.
Скрытый текст
Естественно, всякие рюшечки, в виде буковок различного размера, и всякие пиктограммки не нарисуешь.
Но как по мне, TUI не заслуженно забыт и оставлен в сторонке. Ничто не мешает писать утилиты командной строки таким образом, чтобы они не только получали параметры, опции, команды, но и вполне себе обладали интерфейсом пользователя.
Как, например, htop.
Я бы ещё добавил, что эффективная работа в терминале требует навыка слепого набора текста, без которого в терминале работать становится несколько проблематично. Если оператор медленно набирает двумя пальцами, уткнувшись взглядом в клавиатуру, то крайне велика вероятность пропустить опечатку, с последующим разгадыванием квеста: почему же не сработала команда?
Как-то автор перескочил через TUI. UI не обязательно может быть графическим. Он вполне может быть себе текстовым. Тот же небезызвестный Norton Commander тому пример. А уж сколько софта было написано на текстовом фреймворке TurboVision…
Они не только не умеют считать буквы, они действительно не знают, из каких букв состоит слово. Попросил LLM объяснить, как запомнить ключ -n для указания схемы утилите pg_dump.
Ответ удивил
Слишком много легаси и всевозможных древних зависимостей тащат за собой.
Прошу искренне извинить. Из контекста на Вас подумалось.
Так я ведь с этим и не спорю. Все знают, что seq scan на больших объёмах данных это нехорошо.
Ну да. Это моё восприятие. Мне показалось, что автор имеет ввиду, что для поиска соподчинённых данных нужно всего лишь добавить ключевые поля. Даже своё восприятие аргументировал. А тут мне минусы лепят и рассказывают очевидные вещи о пользе индексирования. Я уж весь мозг изломал, что же я такого крамольного написал.
О, и верно. Был не прав.
Абсолютно согласен. Просто было лениво рисовать pivot таблицу. Но рад, что Вы наконец-то внимательно прочитали текст сообщения и даже потратили время на аргументацию. Жаль, что минус не отозвали.
Каким образом это утверждение соотносится с утверждением автора:
Да ладно?
Держите внешние ключи. Но будет и без них работать, как я и написал выше. Просто просторечно поля вида own_id и pet_id называют внешними ключами, хотя внешние ключи могут быть и не построены.
Я откровенно не понимаю, почему Вы прицепились к сканированию таблицы?
Поясняю, даже без единого индекса, СУБД найдёт искомые записи, уж как оно будет это делать, эффективно или нет, неважно. НАЙДЁТ!
А вот если выкинуть поля own_id и pet_id — НЕ НАЙДЁТ!
В оригинале не идёт речь о том, что можно получить всех владельцев домашнего питомца без использования seq scan. А о том, что их можно получить, добавив...
Вот на мой взгляд, добавив ключевые поля. А никак не индексы.
Я где-то утверждал обратное?
Смотрите внимательно: есть таблица, содержащая виды (типы) домашних питомцев. Всё верно? В оригинале:
Есть таблица владельцев домашних животных. В оригинале:
Получить владельцев домашних питомцев можно создав реляцию между этими двумя таблицами. И индексы здесь не при чём.
Нам нужно ключевое поле, на которое можно ссылаться и индекс по нему может быть вообще не построен. И внешний ключ. Строго говоря, внешний ключ тоже не обязателен. Но для целей самодокументирования и обеспечения ссылочной целостности — крайне желателен.
Вот и получается, что Вы не поняли о чём идёт речь, но минус влепили.
Скорее не индекса, а внешних ключа.