FanatPHP

Слово временный означает "непостоянный". А хранить вы хотите метку времени. Программист как никто должен понимать, как важно четко излагать свои мысли.

Про "нечастые" запросы я не понял. Лет 20 назад, когда единственным способом обновить статус диалога было обновить страницу форума в браузере, это могло бы как-то проканать. А сейчас, когда пользователь ожидает обновления информации не совершая никаких действий, а просто глядя на экран, да ещё и в другом приложении, я не понимаю, как это должно работать. Когда именно приложение должно совершать свои нечастые селекты?

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

Ну как минимум за $table->string('color', 18); надо руки сразу отрывать
То есть на координатах наэкономили, 4 байта в сумме, а потом хоба - в 4 раза больше на несчастный цвет. при том что цветов там явно не больше десятка. И это не говоря уже про нормализацию.

По уму надо придумать простой бинарный протокол, который получает поток байт выравненными кусками
2 байта х
2 байта у
1 байт цвет
4 байта юзер (и нечего жадничать, никаких BigInteger. половины населения земного шара вполне хватит)
то есть всего 9 байт.
а не под сотню, как сейчас - ещё и завернутое в скобочки/кавычечки джейсона

Если подумать, то можно юзера сразу не передавать. Всех юзеров никто смотреть не будет, а при наведении можно и отдельный запрос послать. Тогда можно и BigInteger оставить.
Получится всего 5 байт на пиксель, то есть 10 метров на всю карту. Дофига, но подъемно.

По пагинации это дурь какая-то. Зачем "офсет-лимиты" если уже есть четкая разбивка.
Кто мешает запрашивать тупо построчно? Скажем, по 100 строк картинки? 10 запросов по мегабайту.
id в этой таблице по сути вообще не нужно, только если лара без него не сможет. Но по уму первичный ключ - это ху.

Из БД получать 2 лимона строк конечно тоже не сахар
Но можно наверное увеличить строки, хотя бы виртуально.
Вью или процедура, которая комбинирует скажем сто строк в одну

Насчет других хранилищ я не уверен. Там же наверняка нужна будет выборка обновлений, по таймстампу.
Но в целом с Редисом поэкспериментировать можно.

Ну то есть логика этого вопроса в том, что по какой-то причине файл с БД забэкапить затруднительно, а вот картинки, которые лежат в этом файле - наоборот
Так же и "стороннее средство" в виде команды copy ну вообще ни с чем несовместимо, а создание/разворачивание "дампа" специфическими для БД средствыми доступно на каждом углу.
Не говоря уже про доступ к этим картинкам сторонними средствами.

Все-таки анекдот про Вовочку, "Где логика, где разум?" должен быть девизом этого сайта.

- не станет ли всё это дело тормозить? - не станет
- нужно ли разносить информацию по разным таблицам? - нужно. Плюс таблицы-связки, "заметка-раздел", "заметка-тег". Но сначала надо определиться, чем отличается раздел от категории.
- Как максимально задействовать localStorage? - никак

В юзерах никаких упоминаний картинок быть не должно
В картинках должно быть ещё две колонки, юзер айди и тип - фото, юзер, галерея

вот я тоже не понял, в чем смысл этого "справочника"

А справочник для цифр не хотите ввести? Ну там к примеру датчик показывает 200 миллизюзиков
вы пишете 200 не в таблицу с показаниями, а берете её из справочника показаний, а в таблице с показаниями делается ссылка на это значение.
А можно ещё сделать справочник цифр от 0 до 9, и присоединить его как многие ко многим. Сделать промежуточную таблицу, в которую записать ссылки на цифры 2, 0 и 0. И получить 200 через "понятное присоединение таблиц (join)"!

В реляционной базе данных.

Ну вот разные типы товаров - это классика.
Таблицу можно сделать одну, уникальные для каждого товара характеристики хранить можно в поле джейсон, а искать специальными движкаии типа сфинкса или эластика

На наш взгляд, оптимальнее всего не забивать себе голову детскими фантазиями и высосанными из пальца проблемами.
У тебя нет сайта, нет пользователей, нет одновременной активности, нет проблем с производительностью.
Но зато уже есть ПРОБЛЕМА. Которую надо срочно решать.

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

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

Речь идет только о переводах? Если да, то таблица с 4 полями: иза фильма, ид языка, название, флаг оригинальности.

Статус я бы хранил в отдельной таблице. енум хорош для случаев когда заранее точно известен набор вариантов. Здесь наверняка значения будут добавляться и лучше делать это через обновление данных, а не структуры

Открою тебе тайну.
В твоем компьютере живет волшебный джинн.
Ты только должен сказать ему свое желание, и бац - он тут же даст миллион ответов.
Желание надо писать в адресной строке своего браузера.

Хотелось бы обьединить всех детей в один элемент.

Это вопрос не выборки, а обработки результатов.
База данных не отвечает за формат вывода запрашиваемых данных.

В PHP с использованием PDO для такого простого запроса можно получить группировку с помощью комбинирования режимов FETCH_GROUP и PDO::FETCH_COLUMN

Но при большем уровне вложенности или при необходимости получать какие-либо еще данные кроме имени, нужно будет писать обработчик руками.

если данные атрибутов находятся сериализованные в базе в таблице option,

Взять рельсу, и долго с наслаждением бить по голове того, кто стал хранить данные атрибутов сериализованные в базе в таблице option. Потом добавить по почкам.

Потом перепроектировать базу.
Сделать категории в нормальной таблице, приджойнить к запросу и сортировать по ним.