N

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

Наачиная с 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 приложение), дабы не множить сущности, но если речь идет не об одной физической машине а о кластере, то там есть варианты и сложности.

потому что вы получаете запрос вида where status = 'active' or uid=2 or uid=6; и получаете все варианты.

1. Использовать whereIn

->where('status',  '=' , 'active')
->whereIn('uid',  [2,6])
->get();

2. Использовать обертку что бы получить запрос вида where status = 'active' and (uid=2 or uid=6)

->where('status',  '=' , 'active')
->where(function($builder){
  $builder->where('uid',  '=', '2')
      ->orWhere('uid',  '=', '6');
})
->get();

Многие вопросы на тостере кажутся дурацкими. Но этот самый смешной. Один другому сказал и тот куда-то побежал спрашивать у других.
Но никто не отменял гугл, могли и нагуглить. Headless CMS это обыкновенная CMS, но в отличии от например Wordpress обязательной частью которого является сайт, Headless CMS не имеет никакой прямой связи с сайтом, а реализует API к которой могут подключаться фронтенды и микросевриси написанные на PHP или на Node.js или же вовсе это будут mobile приложения

P.S. Wordpress тоже может быть Headless CMS если заюзать плагины. При этом работу на PHP никто не отменял

Могу сказать, что огромная часть бэка сделанна именно на стареньком php. Думаю из-за того, что большая часть написана именно на php, то логично, что нужны люди которые должны поддерживать уже существующий код. Поэтому я считаю, что php ещё не устарел.
Источник с которого брал инфу: *тык*

Всё же лучше отдельные репозитории.
Или несколько отдельных репозиториев, сгруппированных по функционалу приложения, в которых будут подпапки.
У вас же каждый сотрудник работает в своем форке.
При внимательной организации code review и мержа только по результатам code review большой свалки в проектах и подпроектах быть не должно.

зачем все так усложнять

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

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

Post::where('status', 1)
    ->join('post_tag', 'posts.id', '=', 'post_tag.post_id')
    ->join('tags', 'tags.id', '=', 'post_tag.tag_id')
    ->select('posts.*', DB::raw('group_concat(tags.name) as tags_name'))
    ->groupBy('posts.id', 'posts.name', 'posts.content')->get();

как вариант

Post::where('status', 1)
    ->select('posts.*', DB::raw('select group_concat(tags.name) as tags_name from post_tag join tags on tags.id=post_tag.tag_id where post_tag.post_id = posts.id'))->get();

1) Читаем документацию:

The enctype attribute can be used only if method="post".

2) Файлы не передаются методом get
3) Делаем выводы из 1 и 2.
4) if(isset($_REQUEST['submit'])) - плохая проверка, начиная с того что я могу отправить форму не нажимая кнопку субмит, и заканчивая тем что такой проверкой вы не знаете какой запрос придет с клиента и что в нем будет (то есть вообще ничего кроме этой сомнительной переменной не проверяете).
5) В данной структуре данных вы никак не можете привязать посты к пользователям. Либо нужно добавить поле, определяющее владельца поста, либо делать пивот таблицу, где записывать соответствия пар юзер-пост.
6) Кроме того - у вас в коде отсутствует какое-либо понятие идентификации пользователей, то есть вы не знаете какой пользователь добавляет или запрашивает данные, что делает бесполезным само понятие принадлежности.

Дополню немного ответ Dr. Bacon, поскольку мне кажется он не так понял ваш вопрос, а вы, возможно, не так поняли суть проблемы.
Под БД, например постгрес, обычно понимают две разные вещи:
1) сами данные в файловой системе,
2) сервер базы данных, который реализует сетевой интерфейс для работы с БД и правильным образом кладёт и читает данные в файловой системе.

Так вот, сервер можно развернуть ка кна хостовой машине (как вы сказали "локально"), так и в докер-контейнере.
Файлы БД можно разместить как в файловой системе контейнера, так и в локальной файловой системе, примонтированной внутрь контейнера.
И тут полно нюансов.
Давайте начнём с того, как правильно.
Правиьным будет взять стандартный докер-образ сервера БД, сконфигурировать его через компоуз-файл, а размещение файлов БД примонтировать в виде отдельного volume.

Что имел в виду Dr. Bacon. Он имел в виду, что если не монтировать файлы БД в volume, то они будут лежать внутри контейнера, а значит при его перезапуске все данные будут стерты, поскольку состояние файловой системы контейнера не принято хранить. Это одно из преимузеств докера - сделал образ унаследовав его от других образов, а потом при запуске контейнера он какждый раз как новенький.

SELECT name, `text`
FROM product
JOIN product_attribute USING (product_id)
JOIN attribute_description USING (attribute_id)
-- JOIN attribute USING (attribute_id)   -- таблица в запросе не нужна
GROUP BY 1, 2
HAVING COUNT(*) > 1;

fiddle

Если нужна именно сортировка как в эталоне - ну добавить ORDER BY MAX(attribute_id)

Таблица attribute потребуется лишь в случае, если данные из неё нужны (например, в запрос добавится отбор по значению attribute_group_id).

Если надо сравнивать атрибуты у более чем 2 товаров, то соотв. образом откорректировать условие пост-отбора. Например, для 3 товаров и атрибутов, имеющихся у всех трёх, это будет HAVING COUNT(*) = 3