N

Просто добавьте все параметры которые есть в роуте.
Используйте биндинг, что бы сразу в параметре получить объект.

public function productPage(Category $category, Product $product){
    // $currentProduct = Product::find($product); это уже не нужно
    // В переменной $product уже будет объект
    return view('product', compact('product'));
}

{!! !!}
Раздел документации называется зе бейсикс aka основы, почему бы вам с ним не ознакомиться?

Применительно к данной конкретной задаче:

• СУБД предназначена для хранения и обработки массивов данных.
  
• ЯП предназначен для обеспечения пользовательского интерфейса этого процесса и управления им.
  

По-моему, выбор стороны для проведения обработки очевиден.

Зачем вы в тип DATE пытаетесь записать тип DATETIME?
https://dev.mysql.com/doc/refman/8.0/en/date-and-t...

Ох этот древний ужас не strict режима mysql.

Вы зачем в поле даты пытаетесь вставить строку NOW()? Какая это дата должна быть и почему вам не нравится 1899 год?

INSERT INTO messages(name, content, date) VALUES('${user.name}', '${user.content}',NOW())

Потому-что, нужно так:

INSERT INTO messages(name, content, date) VALUES('${user.name}', '${user.content}', NOW())

Ну и учтите, что date и datetime - это разные типы.

хватит школьных знаний

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

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

Наачиная с MySQL 8.0.14 Вы можете использвать LATERAL:

select * 
from a,
lateral (select * from b where b.a_id = a.id order by d desc limit 1) m;

https://sqlize.online/sql/mysql80/e146f8c70b74a858...

В комментариях тебе уже ответили вариант с order by. Запрос order by и limit очень тяжелый для sql сервера, его очень сложно оптимизировать.

Есть еще min max но тебе нужны id, значит вложенный запрос по timestamp, не уверен что это будет быстрее (лучше поэкспериментируй)

select * from xxx where
   timestamp=(select min(timestamp) from xxx where timestamp > ...)
or timestamp=(select max(timestamp) from xxx where timestamp < ...)

p.s. я заметил что ничего не сказано про одинаковые значения timestamp в разных записях, если брать limit 1 то будет выбираться случайная запись (точнее 100500 раз одна но в какой то момент другая - undefined behavior), этот запрос выдаст все записи с одинаковыми timestamp

Вообще то sql базы данных не очень подходят к задачам, где есть относительный порядок, будут накладные расходы, причем сильно заметные при больших размерах и больших количествах запросов.

В каких то ситуациях можно очень СИЛЬНО оптимизировать задачу, если есть какое то знание о том как данные записываются в таблицу. Например если известно гарантированное окно времени, в течении которого поступают данные, и их не сильно много можно просто сделать

select * from xxx
where timestamp > date - const_interval
  and timestamp < date + const_interval

а затем уже среди этих данных выбирать по выше определенным алгоритмам или даже на бакэнде

Если изменений данных значительно меньше запросов на чтение (особенно если модификации не предполагаются и есть только добавления), то можно складывать искомые значения сразу в момент создания записи (добавлять id новой записи в предыдущую, и тут же ее id в новую), делать это можно как тригерами так и на бакэнде, накладных расходов на такую запись мало зато на чтение данные доступны за константное время, максимально быстро

select p2.*,p3.* from xxx p1
  left join xxx p2 on p1.id=p2.previous_id
  left join xxx p3 on p1.id=p3.next_id
where p1.timestamp=...

в данном случае строчка будет одна, данные раскиданы по колонкам p2.* и p3.*

В каких то ситуациях можно даже завести отдельный сервис, службу, дающую нужный ответ на порядок быстрее чем любой sql (например за счет того что данные хранятся в оперативной памяти), очень часто этим сервисом может стать тот же бакэнд (если это не cgi приложение), дабы не множить сущности, но если речь идет не об одной физической машине а о кластере, то там есть варианты и сложности.