Станислав Макаров

По разному. Я думаю что разные DBMS (SQlite, Oracle) могут по разному обрабатывать группировку.
Правильный ответ на вопрос - посмотреть execution plan комадой
explain (plan) select ..... group by....;
Наперед угадать какой будет использовал алгоритм - невозможно. Как вы помните
язык SQL - это декларативный язык который декларирует свойства результата а не метод
которым разрабочик хочет что-то сделать.

Oracle например имеет много conditions для исполнения группировки например:
1) Какой оценочный объем выборки? Может ли она быть отсортирована in-memory (sort-area-size) в противном
случая будет external sorting в TEMP tablespace.
2) Есть-ли композитный или простой индекс по полям группировки? В этом случае будет index-scan.
3) Требует ли запрос немедленной выдачи первой пачки (хинт +FIRST_ROWS) или можно подождать
но получить весь объем быстрее. Это тоже влияет на выбор алгоритма.

Это всё эвристики которые влияют на выбор окончательного алгоритма.

И уже к сортированной выборке собственно применяется лямбда которая делает группирующую операцию
AVG, SUM, COUNT ... e.t.c. и выдает строки курсора.

Никак.

Если очень хотите головной боли и новых аварий по ночам вместо того чтобы спокойно спать - возьмите какой-нибудь autofailover типа patroni и прочих.

Критичная проблема фундаментальна - CAP теорема в целом и последствия split brain в частности.

ICANN периодически проводит рассмотрение заявок на регистрацию доменов верхнего уровня. Стоимость такого домена порядка $200000 плюс отчисления от продаж поддоменов. Кроме этого вы должны создать и поддерживать инфраструктуру для обслуживания домена.

Напиши на Хабр годную статью и прилепи опрос в конце

EntityReturn - более общий тип относительно Entity, поэтому в EntityReturn можно передавать объекты Entity.

Ошибку про лишнее поле будет показывать, если ты передаешь в EntityReturn литерал с лишними полями:

const entitie: EntityReturn = {
    id: "1",
    filename: ""
};

Переменные надо инициализировать. Без инициализации в них лежит мусор.

Лучшие практики, это что наружу смотрит API которое и обрабатывает поступающие запросы. Никто в здравом уме не выставляет базу на мороз.

Рекурсия нужна при обработке иерархических данных. Например - обойти файлы и каталоги
в файловой системе и выполнить какое-то действие. Или действие с условием. Например если
в текущем фолдере есть фолдер .git - то выполнить какой-то git script.

Рекурсия может понадобиться при работе с документами XML/JSon (шаблон composer). И хотя
в некоторых API рекурсия может быть частично скрыта за языками XPath/JSonPath тем не меннее
ее рекурсивная природа остается налицо. Кроме того если вам достался узкий API типа DomDocument
без поисковых диалектов - то обойти его можно на любом ЯП с рекурсивной функцией.

Рекурсия нужна при парсинге сайтов. Это вобщем просто более расширенная трактовка работы с файловой
системой. Если Url-s это как-бы файлы в web пространстве и они имеют ссылки друг на друга - то вы
можете рекурсией это все обходить.

Рекурсия почти всегда нужна при работе с графами. Берите любой алгорим на теорию графов и я готов
спорить что 99% он будет содержать рекурсию.

Все настольные игры (шахматы-шашки) в основе своего алгоритма альфа-бета поиска с отсечениями и
BWF базируются на рекурсии.

Сам запрос:

Узнайте про PostGIS

Как вообще тестируют нагрузку на БД?

Устраивают DDOS атаку

Не нужно пизать в БД лишнюю логику и лишние ограничения.
У вас с БД работает какой-то софт, например бэкенд. Там и делайте валидаторы данных. В случае пола раньше можно было 1 и 0 удобно хранить и всё было абсолютно интуитивно и понятно, а русскую букву в качестве индекса держать неудобно и неправильно. Во-первых, она в UTF-8, наверняка, что уже как-то изврат для бинарного поля.
Во-вторых, при локализации проблемы могут быть в логах надо юникодовую экранировку читать, если что... в общем либо международное F\M, либо кодами и 1\0 для мнемонического запоминания очень удобно. Вот угадайте что есть что и почему.=)

Но по нынешним временам за такую бинарность могут и засудить=) Не иначе нужна целая таблица гендеров небинарных с названиями, описаниями и локализацией. Да ещё и меняться она будет со временем, а потом при импортах мапить надо одну таблицу полов на другую=).
Шутки шутками, а 0\1 и тут хорошо лягут. Просто идентификаторы такие будут синтетические.

Да, а ограничения делать не надо. Вы могли бы сделать триггер, который при изменении и вставке будет проверять значения полей, но лишняя логика амедляет БД и порой без реальной причины. Если система спроектирована верно, то ничего некорректного в БД попасть не должно.
Многие часто даже от внешних ключей отказываются для ускорения бд, ведь за консистентностью вполне может следить бэкенд, а в каких то случаях лишний процент производительности не помешает.

Ответ: на надо валидировать значения такого рода полей на уровне БД. Делайте так, чтобы нельзя было ввести неверно на уровне ввода данных от пользователя, и дополнительно валидируйте в бэкенде.

С изучения информатики и устройства вычислительной техники. Ну а далее уже можно выбирать что-то из современных ЯП: https://roadmap.sh/computer-science
В целом же, написание кода - лишь одна из частей процесса разработки ПО. Так же рекомендую поставить какую-нибудь игру с редактором карт и освоить его. Например классику: WarCraft 3, StarCraft, HoMM 3.5/4 - легендарные игры, популярность которых обусловлена именно игровыми редакторами и которые смогли пройти сквозь целые эпохи. Возможность самому что-то сделать и поиграть - очень неплохо мотивирует к освоению редакторов и желанию разобраться как оно все работает )

Лао-цзы: «путь в тысячу ли начинается с первого шага»
Брюс Ли: "Я не боюсь того, кто изучает 10,000 различных ударов. Я боюсь того, кто изучает один удар 10,000 раз"
Повторение результата из раза в раз с сохранением того же качества это удел профессионалов. Поэтому много мелких однотипных проектов это даже хорошо, с минимальными усилиями вы нарабатываете будущую клиентскую базу людей которым вы помогаете сейчас и которые будут знать к кому обратиться в будущем. Через 10 лет ваши друзья разбегутся кто куда, станут семейными и откроют бизнес, а в нашей стране очень ценят работу "специалиста по знакомству", но помните любая работа должна быть оплачена и не стоит делать её бесплатно или со скидкой просто потому что знакомые, людей которые захотят вас использовать будет много. Просто примите это как правило.
И еще, все великие начинали с того что брали за основу чьи то наработки и использовали их в своей работе. Поэтому не бойтесь использовать сторонние инструменты, я не говорю вам воровать, но на первых этапах направления которое вы выберете использовать чужое - ок.
Деньги, второстепенное оно приходит с опытом само, не стоит сильно акцентировать внимание на том чтобы заработать миллионы, поверьте это не то что вы хотите на самом деле.
Пока вы молодой, ищите себя в разных направлениях, не бойтесь рисковать и менять работу чтобы к 30 годам уже точно определиться с направлением которое вам близко к душе а не потому что "там больше платят".

И вот еще видео для мотивации.
https://youtu.be/w0Mc2CFxFyE