Задача: Определить порядок поездок для каждого клиента, отсортировав их по времени.
А я в решении прочёл полагание на то, что row_number все сделает за нас. Встречал решения, которые используют подобные предположения, но это сайд эффект, который в параллельной обработке может не сработать.
В запросе номер 4 вернётся просто месиво из данных. Чтобы это была последовательность поездок, надо явно указывать порядок сортировки в order by всего запроса. А тогда row_number() вообще не особо нужен: можно отсортировать по client_id, start_time. Ну и ограничения по числу строк везде отсутствует, как это потом смотреть?
Как-то сложно: класс-генератор дага, который хаком подсовываем в globals созданный даг (потому что для обнаружения нужен вызов на верхнем уровне, который отрабатывает при python -m dagfile.py), хотя можно использовать менеджер контекста with DAG(**conf) as dag: , и магическим образом все внутренние вызовы сложатся в этот даг. А для доступа к предыдущему шагу вполне "из коробки" подходит reduce. И не надо никакой класс.
Это все работает для однотипных задач с минимумом гибкости. Потому что когда-то возникнет мое любимое - передача параметров по пайплайну: в таком виде только xcom_pull с запоминанием id тасков спасет (не дай бог понадобится добавить группировку в таск группы). Ну и минус Jinja, минус питон объекты в качестве параметров (например, колбэки, кастомные расписания, динамически определяемые параметры запуска). Либо ту же Jinja прикручивать в обработчик YAML и парсить в нативные объекты. И вот мы вернулись к исходной задаче: написали YAML конфиг, написали парсер, это все преобразуется в питон объекты и генерирует даг. А можно было сразу написать питон файлы с тем же самым. Отличие только в from my.super.module import DoStuffOperator.
Подскажите, пожалуйста, способ выхода на глобальный рынок без локального. Или без слова "импортозамещение" тот же Яндекс станет компанией добра? Судя по всему, выходит так, что на локальном рынке только "быдланы", слушающие русский рэп (то есть 100% слушателей), а вот в глобальном - одни интеллектуалы и розовые пони, которые слушают правильную музыку. На том же Яндексе я узнал много хороших отечественных групп, что я делаю не так?
Хранить секреты можно в стандартных connection Airflow: там есть и аудит, и шифрование, и маскирование в логах. Доп параметры типа ID чата можно разместить в extra подключения. Тогда функцию считывания можно упростить, да и управление единообразное.
Так ровно по этой причине оракл не может вставить колонку в середину, иначе придется перелопатить все данные и устроить в них chained rows. Так как СУБД все же стала уделом программистов, и запросы типа select * не частые гости в UI (или как минимум являются бомбой замедленного действия), то порядок колонок после добавления чаще всего мало кого волнует. Если очень хочется навести порядок и использовать магию с наллами, то есть как альтернативные способы хранения разреженных данных, так и online redefinition. А вот как в MySQL реализована вставка колонки в середину при конкурентных апдейтах/инсертах и насколько оно действительно хорошо работает - интересный вопрос.
Сервер приложений SAP написан на ЯП 80-х годов, который взял многое из COBOL и который хоть и обогащался новыми фичами, но так и оставил легаси. Почему-то в 2024 году компании все ещё не гнушаются им пользоваться, а пользователи, не поверите, спокойно смотрят в без преувеличения УЖАСНЕЙШЕ выглядящие UI. А все потому, что они в нем работают, а не тестируют новые фичи ЯП и не любуются красотой кода.
TaskFlow API это не программная генерация структуры дага, а возможность писать флоу в виде вызовов Python-функций как обычный код вместо декларативного и многословного "рисования стрелочек" с передачей параметров откуда-то сбоку: Airflow при этом сам генерирует DAG из этих простых вызовов, делает XCom.push/pull.
А вот насчёт GUI не сказать, что очень продвинутый. Создавать задания там нельзя, только смотреть. Причем в версиях после 2.5 ветвистый граф на десятки задач с несбалансированным ветками рисуется некрасиво. Фильтрации задач по имени и тегирования тасков в графе нет, только подсветка. Обычный листинг всех дагов с тегами и фильтрами, никакой структуры хранения дагов ввести нельзя. Но вообще GUI постоянно дорабатывают и добавляют новые фичи.
Ох, проходили ведь уже. COBOL, SQL, BI-инструменты, HTML. Как-то не дождешься, чтобы бизнес этим пользовался. Все равно отдают разного уровня абстракции «программистам».
"В ее основе могут лежать таблицы". Что значит могут? Статься про SQL, т.е. РСУБД, и таблицы - это основной объект хранения данных в РСУБД. Упущено какое-либо описание таблиц вообще: я много раз сталкивался с тем, что даже не джуны не знают, что таблицы в БД не имеют какого-либо порядка строк и оперируют понятиями "первая", "как в таблице" и т.п., видел сотни строк кода, которые делают select ... limit 1, и потом сидишь разгребаешь проблемы, что их программная логика, которая "работала годами", не переносится на язык SQL и обработку в СУБД.
Типы связей в БД - полет фантазии. Связь one-to-one, one-to-many не имеет никакого отношеня как к самой БД, так и к метаданным БД. Это понятия логической модели, отражающей объекты реального мира, СУБД это никак не проверяет и в SQL нет явного способа это указывать. Можно декларировать, что связь будет 1..N, при этом за всю историю существования БД ни одной пары записей в таком отношении не будут добавлены в БД. Пример с 1..N абсолютно неправильный: это что за модель, где таблица авторов ссылается на таблицу книг? Автор пишет одну книгу за всю жизнь?.
TRUNCATE, который удаляет таблицу и падает, если на нее есть ссылка. Это где такие чудеса делаются? Что за выдумки? В Oracle, например, с объектом вообще ничего не происходит, только переставляется HWM в начало сегмента. В PG тоже файлы отвязываются от таблицы и все.
"HAVING применяется к группам строк после их формирования в результате использования агрегатных функций" - снова мимо. Для работы HAVING не требуется наличие агрегатных функций вообще, и агрегатные функции не формируют группы сами по себе. HAVING отрабатывает после GROUP BY и может использовать любые выражения из GROUP BY, любые агрегатные функции, примененные к остальным выражениям, либо скалярные выражения от выражений из первых двух категорий.
1NF в реляционной БД существует по-умолчанию, т.к. это основа организации данных в реляционной БД (таблицах).
Дальше не осилил. Слишком много фактических ошибок на абзац.
А у меня есть реальный пример, но в другой компании. Было это в 2012 году, на тот момент от студентов как правило не ждали никакого прикладного опыта.
Приходит сосед по комнате, рассказывает свой опыт собеседования. Спрашивали у него разного рода теорию по матану, теорверу, решение дифференциальных уравнений. Из того, что мне очень хорошо запомнилось: разложение в ряд Тейлора с остаточным членом в форме Пеано, в форме Коши и в форме Лагранжа с доказательствами и практическим разложением по всем трём вариантам некоторой функции. Компанию, в которую он устраивался, я знал как большой магазин компьютерной техники, в связи с чем был очень удивлен такому набору вопросов. Ну ладно, думаю, может аналитика какая. Встречаемся через месяц, спрашиваю, как чего, товарищ рассказывает. Сначала он следил по камерам за конвейером и записывал, сколько ноутбучных сумок проезжает за определенный промежуток времени, а сколько остальных товаров. Потом его посадили рядом с сотрудником, который работает за компьютером, и он трекал его время по интервалам: сколько работает в какой программе, сколько ходит на обед и когда, сколько в туалет. И все это в конце дня куда-то вносил. Я слушал и не верил, т.к. мне казалось, что более идиотичной "работы" быть вообще не может. Я в это время устроился в консалтинг и занимался изучением там BI-инструмента и СУБД Oracle. Платили ему примерно в полтора раза больше, причем там поощрялись переработки, за которые платили по повышенной ставке, чему мой товарищ был рад.
Зачем был нужен матан я понял сильно позже: основатели компании закончили физтех. Полагаю, не могли себе морально позволить нанять абы кого в свою компанию. Спустя два месяца снова созванивались с ним: я в это время шел на обед с коллегами, и для него было неожиданным услышать такой ответ, ведь сам он уволился из своей помойки. Матан применить так и не пришлось, видимо, этот уровень открывался сильно позже.
Речь идёт об абсолютно одинаковых запросах с CTE и с подзапросом в FROM/JOIN или о разных запросах? В первом случае это было бы очень странное и неожиданное поведение оптимизктора, т.к. семантически CTE и inline ничем не различаются: один и тот же текст SQL, где какой-то части дано имя (хотя и inline подзапросу дается алиас). Если это разные запросы, особенно в случае переписывания на подзапрос с корреляцией, то неудивительно. Все же CTE стоит рассматривать в первую очередь как инструмент улучшения читаемости и следование принципу DRY, а потенциальные свызанные с ним оптимизации - как побочный эффект. Хотя в случае с SQL Server, возможно, есть какие-то подводные камни с этой конструкцией.
Очень странная статья. Начали с T-SQL, потом перешли на Oracle. Решения без объяснений, некоторые переусложнены непонятно зачем: к примеру, чтобы устранить дубликаты в одноколоночной выборке, я бы никогда не использовал row_number, для этого есть district; а в первом задании наоборот row_number/dense_rank помог бы решить задачу за один проход по таблице.
Задания вида "как мне получить вот такой результат" считаю издевательством, и верным решением такой задачи спокойно можно считать выборку констант через union. Потому что результат нужно формулировать словами, чтобы был понятен алгоритм вычисления, а не гадать на кофейной гуще, как это должно быть посчитано (тем более наверняка семпл данных нерепрезентативен, и потом посыплется куча частных случаев, которые решение не обрабатывает).
За имена в двойных кавычках в Oracle стоит давать по рукам... и сажать на вечную поддержку такого решения. Желательно создав перед этим пару таблиц с кириллическими О, А, С в названиях.
Последний вариант ведь отличается от первого: таблицы читаются каждая в свой промежуток времени, результаты выполнения будут разные, если в таблицы постоянно что-то пишется. Рассуждение о прозводительности запросов в РСУБД без предоставления планов запросов - это чисто гадание: непонятно, почему стало быстрее, почему было медленно, какие ожидания по кардинальностям у планировщика и какие фактические кардинальности, и будет ли оно так же быстро через два месяца. Глядя только на код PL/SQL непонятно, почему обычный JOIN медленнее многократного выполнения одного запроса к таблице (на каждую итерацию цикла), если со статистикой все в порядке (тем более Oracle умеет TABLE ACCESS BY INDEX ROWID BATCHED, если в случае с PL/SQL выстрелил доступ по индексам).
Также вопрос к исходному запросу: зачем использовать JOIN для фильтрации, если в SQL для этих целей существует явный IN/EXISTS?
Начиная с версии 2.0, в Airflow есть TaskFlowAPI, который позволяет описывать даги и таски как обычные функции Python, добавляя к ним декоратор @dag и @task. Это значительно сокращает переписывание шаблонного кода, передачу ненужных параметров наподобие dag_id и op_kwargs (первый определяется из вышестоящего дага при добавлении таска в него, а второй - из определения функции). Добавление таска - вызов функции, явная связь тасков - передача результата одной функции (таска) в аргументы другой безо всяких xcom_pull. С учётом того, что вторая версия вышла 3 года назад, странно до сих пор видеть нагромождение этих явных деклараций тасков.
Это не "выбрано определение x^0=1", а получается по определению функции f(y) = x^y, x!=0, что и показано выше. В чем разница: "выбрано определение" означает, что у нас есть значок ^ (откуда-то) и нам надо его определить, а на самом деле мы придумали, что многократное умножение было бы здорово обозначать значком ^, и дальше мы можем исследовать его свойства исходя из определения этого значка (и логично, что значок мы определяем сначала для ненулевого основания, т.к. умножение нулей на себя даёт нули, а деление вообще невозможно). По определению операции получается, что для ненулевых x возведение в нулевую степень даёт 1, как уже показано. И далее важно помнить, что аргумент у нас - показатель степени. Если мы начинаем говорить 0^0, то это совсем другая задача о функции двух аргументов: доопределить функцию f(x,y)=x^y в точке (0,0). И не стоит все смешивать разом.
Такое ощущение, что текст про индексы кочует из одного места в другое примерно в одном и том же состоянии, т.к. уже много раз встречал эти расплывчатые формулировки про ускорение выборки и замедление обновления. Никак не упоминается, за счет чего происходит ускорение, в каких случаях это может быть полезно, а в каких нет. Про замедление делитов вообще интересно: delete нужно делать точечно, и там индексы как раз помогут; а если удаляется половина таблицы, то, возможно, стоит пересмотреть подход к очистке через truncate, и тогда даже с учетом перестроения индексов будет значительно быстрее, чем делиты.
Компоновка вопросов странная: в одном вопросе про агрегацию и create table. Зачем-то вопросы про NoSQL (хотя этот термин относится к СУБД, а не к базе как таковой), ведь системный аналитик не занимается выбором технологии. Про версионность описано что-то очень сумбурное: это про flashback/as of timestamp запросы? Тогда структуры таблиц не откатываются (по крайней мере в явном виде SQL-таблиц).
Более того, в некоторых интерпретаторах \w отлично мэтчит кириллицу и остальные наборы буквенных символов, что в условиях того языка, на котором мы тут общаемся, очень удобно. Городить аналог для юникода как раз испортит читаемость
Про нумерацию даже не сказано.
А я в решении прочёл полагание на то, что row_number все сделает за нас. Встречал решения, которые используют подобные предположения, но это сайд эффект, который в параллельной обработке может не сработать.
В запросе номер 4 вернётся просто месиво из данных. Чтобы это была последовательность поездок, надо явно указывать порядок сортировки в order by всего запроса. А тогда row_number() вообще не особо нужен: можно отсортировать по client_id, start_time. Ну и ограничения по числу строк везде отсутствует, как это потом смотреть?
Как-то сложно: класс-генератор дага, который хаком подсовываем в globals созданный даг (потому что для обнаружения нужен вызов на верхнем уровне, который отрабатывает при
python -m dagfile.py), хотя можно использовать менеджер контекстаwith DAG(**conf) as dag:, и магическим образом все внутренние вызовы сложатся в этот даг. А для доступа к предыдущему шагу вполне "из коробки" подходитreduce. И не надо никакой класс.Это все работает для однотипных задач с минимумом гибкости. Потому что когда-то возникнет мое любимое - передача параметров по пайплайну: в таком виде только
xcom_pullс запоминанием id тасков спасет (не дай бог понадобится добавить группировку в таск группы). Ну и минус Jinja, минус питон объекты в качестве параметров (например, колбэки, кастомные расписания, динамически определяемые параметры запуска). Либо ту же Jinja прикручивать в обработчик YAML и парсить в нативные объекты. И вот мы вернулись к исходной задаче: написали YAML конфиг, написали парсер, это все преобразуется в питон объекты и генерирует даг. А можно было сразу написать питон файлы с тем же самым. Отличие только вfrom my.super.module import DoStuffOperator.Подскажите, пожалуйста, способ выхода на глобальный рынок без локального. Или без слова "импортозамещение" тот же Яндекс станет компанией добра? Судя по всему, выходит так, что на локальном рынке только "быдланы", слушающие русский рэп (то есть 100% слушателей), а вот в глобальном - одни интеллектуалы и розовые пони, которые слушают правильную музыку. На том же Яндексе я узнал много хороших отечественных групп, что я делаю не так?
Хранить секреты можно в стандартных connection Airflow: там есть и аудит, и шифрование, и маскирование в логах. Доп параметры типа ID чата можно разместить в extra подключения. Тогда функцию считывания можно упростить, да и управление единообразное.
То ли Яндекс как обычно: изменение ради изменения, тестировать не обязательно, все равно релиз через неделю. Надо же чем-то занять разрабов.
Так ровно по этой причине оракл не может вставить колонку в середину, иначе придется перелопатить все данные и устроить в них chained rows. Так как СУБД все же стала уделом программистов, и запросы типа select * не частые гости в UI (или как минимум являются бомбой замедленного действия), то порядок колонок после добавления чаще всего мало кого волнует. Если очень хочется навести порядок и использовать магию с наллами, то есть как альтернативные способы хранения разреженных данных, так и online redefinition. А вот как в MySQL реализована вставка колонки в середину при конкурентных апдейтах/инсертах и насколько оно действительно хорошо работает - интересный вопрос.
Сервер приложений SAP написан на ЯП 80-х годов, который взял многое из COBOL и который хоть и обогащался новыми фичами, но так и оставил легаси. Почему-то в 2024 году компании все ещё не гнушаются им пользоваться, а пользователи, не поверите, спокойно смотрят в без преувеличения УЖАСНЕЙШЕ выглядящие UI. А все потому, что они в нем работают, а не тестируют новые фичи ЯП и не любуются красотой кода.
TaskFlow API это не программная генерация структуры дага, а возможность писать флоу в виде вызовов Python-функций как обычный код вместо декларативного и многословного "рисования стрелочек" с передачей параметров откуда-то сбоку: Airflow при этом сам генерирует DAG из этих простых вызовов, делает XCom.push/pull.
А вот насчёт GUI не сказать, что очень продвинутый. Создавать задания там нельзя, только смотреть. Причем в версиях после 2.5 ветвистый граф на десятки задач с несбалансированным ветками рисуется некрасиво. Фильтрации задач по имени и тегирования тасков в графе нет, только подсветка. Обычный листинг всех дагов с тегами и фильтрами, никакой структуры хранения дагов ввести нельзя. Но вообще GUI постоянно дорабатывают и добавляют новые фичи.
Только в центре Азии или Африки? Ведь там не люди живут, не то, что в Европе
Ох, проходили ведь уже. COBOL, SQL, BI-инструменты, HTML. Как-то не дождешься, чтобы бизнес этим пользовался. Все равно отдают разного уровня абстракции «программистам».
"В ее основе могут лежать таблицы". Что значит могут? Статься про SQL, т.е. РСУБД, и таблицы - это основной объект хранения данных в РСУБД. Упущено какое-либо описание таблиц вообще: я много раз сталкивался с тем, что даже не джуны не знают, что таблицы в БД не имеют какого-либо порядка строк и оперируют понятиями "первая", "как в таблице" и т.п., видел сотни строк кода, которые делают
select ... limit 1, и потом сидишь разгребаешь проблемы, что их программная логика, которая "работала годами", не переносится на язык SQL и обработку в СУБД.Типы связей в БД - полет фантазии. Связь one-to-one, one-to-many не имеет никакого отношеня как к самой БД, так и к метаданным БД. Это понятия логической модели, отражающей объекты реального мира, СУБД это никак не проверяет и в SQL нет явного способа это указывать. Можно декларировать, что связь будет 1..N, при этом за всю историю существования БД ни одной пары записей в таком отношении не будут добавлены в БД. Пример с 1..N абсолютно неправильный: это что за модель, где таблица авторов ссылается на таблицу книг? Автор пишет одну книгу за всю жизнь?.
TRUNCATE, который удаляет таблицу и падает, если на нее есть ссылка. Это где такие чудеса делаются? Что за выдумки? В Oracle, например, с объектом вообще ничего не происходит, только переставляется HWM в начало сегмента. В PG тоже файлы отвязываются от таблицы и все.
"
HAVINGприменяется к группам строк после их формирования в результате использования агрегатных функций" - снова мимо. Для работы HAVING не требуется наличие агрегатных функций вообще, и агрегатные функции не формируют группы сами по себе. HAVING отрабатывает после GROUP BY и может использовать любые выражения из GROUP BY, любые агрегатные функции, примененные к остальным выражениям, либо скалярные выражения от выражений из первых двух категорий.1NF в реляционной БД существует по-умолчанию, т.к. это основа организации данных в реляционной БД (таблицах).
Дальше не осилил. Слишком много фактических ошибок на абзац.
А у меня есть реальный пример, но в другой компании. Было это в 2012 году, на тот момент от студентов как правило не ждали никакого прикладного опыта.
Приходит сосед по комнате, рассказывает свой опыт собеседования. Спрашивали у него разного рода теорию по матану, теорверу, решение дифференциальных уравнений. Из того, что мне очень хорошо запомнилось: разложение в ряд Тейлора с остаточным членом в форме Пеано, в форме Коши и в форме Лагранжа с доказательствами и практическим разложением по всем трём вариантам некоторой функции. Компанию, в которую он устраивался, я знал как большой магазин компьютерной техники, в связи с чем был очень удивлен такому набору вопросов. Ну ладно, думаю, может аналитика какая. Встречаемся через месяц, спрашиваю, как чего, товарищ рассказывает. Сначала он следил по камерам за конвейером и записывал, сколько ноутбучных сумок проезжает за определенный промежуток времени, а сколько остальных товаров. Потом его посадили рядом с сотрудником, который работает за компьютером, и он трекал его время по интервалам: сколько работает в какой программе, сколько ходит на обед и когда, сколько в туалет. И все это в конце дня куда-то вносил. Я слушал и не верил, т.к. мне казалось, что более идиотичной "работы" быть вообще не может. Я в это время устроился в консалтинг и занимался изучением там BI-инструмента и СУБД Oracle. Платили ему примерно в полтора раза больше, причем там поощрялись переработки, за которые платили по повышенной ставке, чему мой товарищ был рад.
Зачем был нужен матан я понял сильно позже: основатели компании закончили физтех. Полагаю, не могли себе морально позволить нанять абы кого в свою компанию. Спустя два месяца снова созванивались с ним: я в это время шел на обед с коллегами, и для него было неожиданным услышать такой ответ, ведь сам он уволился из своей помойки. Матан применить так и не пришлось, видимо, этот уровень открывался сильно позже.
Речь идёт об абсолютно одинаковых запросах с CTE и с подзапросом в FROM/JOIN или о разных запросах? В первом случае это было бы очень странное и неожиданное поведение оптимизктора, т.к. семантически CTE и inline ничем не различаются: один и тот же текст SQL, где какой-то части дано имя (хотя и inline подзапросу дается алиас). Если это разные запросы, особенно в случае переписывания на подзапрос с корреляцией, то неудивительно. Все же CTE стоит рассматривать в первую очередь как инструмент улучшения читаемости и следование принципу DRY, а потенциальные свызанные с ним оптимизации - как побочный эффект. Хотя в случае с SQL Server, возможно, есть какие-то подводные камни с этой конструкцией.
Очень странная статья. Начали с T-SQL, потом перешли на Oracle. Решения без объяснений, некоторые переусложнены непонятно зачем: к примеру, чтобы устранить дубликаты в одноколоночной выборке, я бы никогда не использовал row_number, для этого есть district; а в первом задании наоборот row_number/dense_rank помог бы решить задачу за один проход по таблице.
Задания вида "как мне получить вот такой результат" считаю издевательством, и верным решением такой задачи спокойно можно считать выборку констант через union. Потому что результат нужно формулировать словами, чтобы был понятен алгоритм вычисления, а не гадать на кофейной гуще, как это должно быть посчитано (тем более наверняка семпл данных нерепрезентативен, и потом посыплется куча частных случаев, которые решение не обрабатывает).
За имена в двойных кавычках в Oracle стоит давать по рукам... и сажать на вечную поддержку такого решения. Желательно создав перед этим пару таблиц с кириллическими О, А, С в названиях.
Последний вариант ведь отличается от первого: таблицы читаются каждая в свой промежуток времени, результаты выполнения будут разные, если в таблицы постоянно что-то пишется. Рассуждение о прозводительности запросов в РСУБД без предоставления планов запросов - это чисто гадание: непонятно, почему стало быстрее, почему было медленно, какие ожидания по кардинальностям у планировщика и какие фактические кардинальности, и будет ли оно так же быстро через два месяца. Глядя только на код PL/SQL непонятно, почему обычный JOIN медленнее многократного выполнения одного запроса к таблице (на каждую итерацию цикла), если со статистикой все в порядке (тем более Oracle умеет TABLE ACCESS BY INDEX ROWID BATCHED, если в случае с PL/SQL выстрелил доступ по индексам).
Также вопрос к исходному запросу: зачем использовать JOIN для фильтрации, если в SQL для этих целей существует явный IN/EXISTS?
Начиная с версии 2.0, в Airflow есть TaskFlowAPI, который позволяет описывать даги и таски как обычные функции Python, добавляя к ним декоратор
@dagи@task. Это значительно сокращает переписывание шаблонного кода, передачу ненужных параметров наподобиеdag_idиop_kwargs(первый определяется из вышестоящего дага при добавлении таска в него, а второй - из определения функции). Добавление таска - вызов функции, явная связь тасков - передача результата одной функции (таска) в аргументы другой безо всякихxcom_pull. С учётом того, что вторая версия вышла 3 года назад, странно до сих пор видеть нагромождение этих явных деклараций тасков.Это не "выбрано определение
x^0=1", а получается по определению функцииf(y) = x^y, x!=0, что и показано выше. В чем разница: "выбрано определение" означает, что у нас есть значок^(откуда-то) и нам надо его определить, а на самом деле мы придумали, что многократное умножение было бы здорово обозначать значком^, и дальше мы можем исследовать его свойства исходя из определения этого значка (и логично, что значок мы определяем сначала для ненулевого основания, т.к. умножение нулей на себя даёт нули, а деление вообще невозможно). По определению операции получается, что для ненулевыхxвозведение в нулевую степень даёт 1, как уже показано. И далее важно помнить, что аргумент у нас - показатель степени. Если мы начинаем говорить0^0, то это совсем другая задача о функции двух аргументов: доопределить функциюf(x,y)=x^yв точке (0,0). И не стоит все смешивать разом.Такое ощущение, что текст про индексы кочует из одного места в другое примерно в одном и том же состоянии, т.к. уже много раз встречал эти расплывчатые формулировки про ускорение выборки и замедление обновления. Никак не упоминается, за счет чего происходит ускорение, в каких случаях это может быть полезно, а в каких нет. Про замедление делитов вообще интересно: delete нужно делать точечно, и там индексы как раз помогут; а если удаляется половина таблицы, то, возможно, стоит пересмотреть подход к очистке через truncate, и тогда даже с учетом перестроения индексов будет значительно быстрее, чем делиты.
Компоновка вопросов странная: в одном вопросе про агрегацию и create table. Зачем-то вопросы про NoSQL (хотя этот термин относится к СУБД, а не к базе как таковой), ведь системный аналитик не занимается выбором технологии. Про версионность описано что-то очень сумбурное: это про flashback/as of timestamp запросы? Тогда структуры таблиц не откатываются (по крайней мере в явном виде SQL-таблиц).
Более того, в некоторых интерпретаторах \w отлично мэтчит кириллицу и остальные наборы буквенных символов, что в условиях того языка, на котором мы тут общаемся, очень удобно. Городить аналог для юникода как раз испортит читаемость