Ахах, как вариант

Ага жалобы тоже можно хранить в городском архиве)

Я серьёзно. Он что сука времени не находит на составление нормальных заданий?

Нахера он там нужен с такими заданиями

😝Денчик встал не с той ноги сегодня))

Препод норм, но вот задание я считаю крайне мало описано

Да уже не первый раз подобное слышу. И видел нормальные задания

Какой толк от таких заданий? Ну сделаешь ты сейчас самый простой вариант и что? Он вас должен задрачивать на составление сложных DDL и потом оттуда вынимать данные трехэтажными запросами

К тому же в реальной жизни у тебя вряд ли попадётся подобное. Всегда есть требования, а не просто сделай БД свинарника. Всегда будут конкретные сущности, которые нужно хранить и порой связать их не просто

Даже если ты себе будешь пилить сервис, ты будешь конкретно понимать что тебе нужно хранить и как. Например шахматный бот требует разной структуры БД для инлайн режима и для работы изнутри самого бота. И эти требования вытекают из ограничений интерфейса. А если просто сказать сделай бд шахмат — получится херь какая-то.

Вынимать данные трехэтажными запросами?
Вот за это я ненавижу _MYSQL_-"программистов"... )))
mysql - он вообще не про трехэтажные запросы. Это - ораклы т.п.
Мускул должен работать быстро. Первую главу руководства, которую должны учить наизусть мускульные программисты - это "Как mysql использует индексы?"
А второе - как можно функциональность трехэтажных запросов заменить простыми запросами.

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

CREATE TABLE `games` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `whites_id` bigint(20) unsigned NOT NULL,
  `blacks_id` bigint(20) unsigned NOT NULL,
  `inline_id` varchar(255) NOT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `config` text,
  PRIMARY KEY (`id`),
  UNIQUE KEY `games_inline_id_unique` (`inline_id`),
  CONSTRAINT `games_blacks_id_foreign` FOREIGN KEY (`blacks_id`) REFERENCES `users` (`id`),
  CONSTRAINT `games_whites_id_foreign` FOREIGN KEY (`whites_id`) REFERENCES `users` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `moves` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `game_id` int(10) unsigned NOT NULL,
  `entry` varchar(255) DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `moves_game_id_index` (`game_id`),
  CONSTRAINT `moves_game_id_foreign` FOREIGN KEY (`game_id`) REFERENCES `games` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `users` (
  `id` bigint(20) unsigned NOT NULL,
  `is_bot` tinyint(1) DEFAULT NULL,
  `first_name` varchar(255) DEFAULT NULL,
  `last_name` varchar(255) DEFAULT NULL,
  `username` varchar(255) DEFAULT NULL,
  `language_code` varchar(255) DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `users_language_code_IDX` (`language_code`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

А ты сам на чем пишешь то?

Отличный пример. Именно об этом я и говорю - это НЕ программирование!

Но пункту 3. Например, я сохранял в таблице игр количество ходов. Или сохранял бы в таблице ходов время каждого хода.

Нужно мыслить на результат. А не абстракциями.
В институтах же учат написать минимально возможную ДДЛ, а потом изгаляться, чтобы извлечь данные.
Это - бред. Нужно хранить данные так, чтобы их можно было быстро и удобно извлекать в нужный момент.
Винты и память стоят копейки по сравнению с процессором. Sic! Нет ничего плохого в дублировании данных или создании отдельной таблицы под конкретный запрос.

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

Но да, в универах палку перегибают. Практически никому и никогда не нужна 5нф в проде.
Нужно искать баланс между удобством и адекватностью))

есть два запроса:
1.
select * from adress
where adr REGEXP '^[0-9]{1,6}$';
2.
Update adress
set adr=concat("text ", substring(adr, 1,1))
where adr REGEXP '^[0-9]{1,6}$';

как так, в первом запросе почти 4000 строк, а второй ни одной?
как так? условия одинаковые (тупо скопированные из одного запроса в другой)

А ты не думаешь, что кроме ошибок, для записи в несколько мест, требуется больший ресурс процессора?

То что ты не можешь написать даже такой простейший запрос было и до этого очевидно. Но кто же тебе сказал, что большой запрос всегда является долгим? Мой запрос делающий это отрабатывает за 593 мс, когда в таблице 30К игр и 350К ходов. Предложение сохранять кол-во ходов и игр за день является лютейшим бредом и сделано тобой, потому что ты ничего не смыслишь ни в реляционной алгебре, ни в разработке чего-либо вообще — в этом я уверен.

Если что, я не MySQL-"программист", ссылка на мой гитхаб в самом конце моего био.

А с чего вдруг, UPDATE тебе должен что-то возвращать?

И срачи устраивать в чате я тебе не позволю