ThunderCat

Подскажите пожалуйста как сохранить модель Doctors как авторизованного пользователя?

1) Модели не называются во множественном числе. Модель Doctor привязывается к таблице doctors. И "я получаю модель Users," - то же самое, модель User.
2) Доктор или пациент это не пользователь, это либо роль, и тогда надо делать RBAC, либо авторизированная сущность, и тогда нужно связывать юзера и сущность через один-к-одному, в случае если доктор и пациент кардинально различаются по свойствам, а не просто имеют разные права. А пользователь просто способ авторизации/идентификации.

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

1) Веб разработка. В свою очередь делится на 2 поднаправления: фронтенд - все что отрисовывается и обрабатывается на клиенте (то есть проще говоря в браузере), и бэкенд - все что относится к работе со стороны сервера. Фронтенд, как это ни странно, ограничен в языках более всего, тут только яваскрипт или что-то типа тайпскрипта, которое по итогоу в яваскрипт "компилируется". Бэк в этом плане более разношерстный, тут можно практически все использовать, но мэйнстрим это пхп, питон, ява, сишарп, руби-рельсы. Первые два в основном используют студии вебразработки, вторые два - в основном энтерпрайз, последний уже больше экзотика.
2) Геймдев. Как ни странно, тоже делится на 2 поднаправления: казуалки/мобилы и большие триплА проекты. В первом случае это сишарп + юнити (да, это не язык, а инструмент, но без него стек не полный), в редком случае что-то экзотическое. Во втором это скорее всего си++ и какой-то фреймворк, а-ля анриал или вулкан.
3) Энтерпрайз. Тут стандарт де факто - ява. Как вариант Сишарп, но гораздо реже.
4) Десктоп приложения. Простенькие консольные можно писать практически на чем угодно, более-менее обладающее интерфейсом тербует соответствующих gui библиотек, по типу Qt, gtk, ну и соответственно языков типа ява, си++, сишарп... Хочу заметить, что направление это весьма дохлое, в плане того что именно приложения для широких масс в последнее время практически не выпускаются, уступая место вебсервисам или мобильным приложениям, которые тоже не ахти какие рынки занимают...
5) Мобильная разработка. Зверь редкий, так как под мобилы больше игры делают. Именно разработка приложений достаточно узкий сегмент, ну и опять же - делится на разработку под андроид и под айфон. В первом случае языком разработки будет Котлин(в девичестве Ява), под айфон соответственно будет Свифт. Есть решения кроссплатформенные, по типу флаттера, но это не всегда подходит, так как некоторые функции под конкретную платформу будут недоступны.

Короче, определяетесь с направлением, пробуете, не нравится - берете следующее, с языками так же. По тому "в чем писать" определяться стоит по запросу "среда разработки для %языкнейм%"

$q = "INSERT INTO post(author, date_p, text_p) VALUES ('$author', '$datep', '$text_content')"; 
//  ";" в одиночных запросах не ставится, а текстовые значения обрамляются кавычками
var_dump($q); //смотрим глазками, проверяем в консоли
$q = "INSERT INTO post(author, date_p, text_p) VALUES (?, ?, ?)"; 
//никогда не лезем в бд без подготовленных выражений!
$st = $pdo->prepare($q);
$sth->execute([$author, $datep, $text_content]);

Мне нужно что-бы функция вернула корни уравнения в виде массива.

Она возвращает

Однако я получаю пустоту.

Однако не получаете

Почему?

Скорее всего вы подразумевали не "получение" а "вывод". Но никакого вывода на экран вы не используете.

Не работает return PHP. Ничего не выводит на экран, что делать?

Формально ответ - по тому что "получение"/"возвращение" и "вывод" абсолютно разные вещи.

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

Что делается для "хайлоадинга"?
1) Меняются сервера на помощнее, но это больше к админам обычно.
2) Выявляются узкие места, в подавляющем большинстве случаев это либо обращения к бд, либо работа со сторонними сервисами, а-ля АПИ фейсбука и все такое.

Как разгонять именно такие затыки 2 варианта - есть 3 пути:
1) Оптимизация. Все что возможно ускорить - ускоряется, находятся самые тормознутые запросы, прогоняются через explain, переписываются, тюнятся, индексируются до состояния максимальной производительности.
2) Кэширование. Обычно используют кей-валуе инмемори хранилища а-ля мемкеш и редис, и результаты запросов часто используемых, но не часто обновляемых данных пишутся в кэш. Время жизни настраивается в зависимости от необходимой актуализации. По идее на высоких нагрузках даже кэш с времением жизни 5-10 секунд может в разы снизить нагрузку на сервера.
3) Иногда стандартных средств и инструментов не достаточно, и нужно искать какие-то новые инструменты, например переходить на сфинкс, так как фултекстсерч не вывозит. Или большие объемы данных идут на запись, и стандартной пропускной способности бд уже не хватает и нужно что-то типа систем хранения логов, или наоборот, аналитические бд по типу кликхауса...

Короче - все то же самое что и в стандарте, только оттюнено и обмазано кэшами и инструментами чуть сложнее мускуля...

Во первых нужно нормально писать запрос, хотя бы для понимания что вы делаете:

SELECT DISTINCT tt.term_id 
FROM wp_term_relationships AS tr 
JOIN wp_term_taxonomy AS tt 
ON tr.term_taxonomy_id = tt.term_taxonomy_id 
JOIN wp_terms AS t 
ON tt.term_id = t.term_id 
WHERE tr.object_id IN (
   SELECT p.ID 
   FROM wp_posts AS p 
   JOIN wp_term_relationships AS tr 
   ON p.ID = tr.object_id 
   JOIN wp_term_taxonomy AS tt 
   ON tr.term_taxonomy_id = tt.term_taxonomy_id 
   JOIN wp_terms AS t 
   ON tt.term_id = t.term_id 
   WHERE p.post_type = 'product' 
   AND p.post_status = 'publish' 
   AND tt.taxonomy = 'product_cat' 
   AND t.term_id = '2961' 
) 
AND tt.taxonomy LIKE 'pa_%';

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

Ну и в третьих, запросы без лимита почти всегда будут медленными, так как бд вынуждена перебирать все таблицы перебором. Если же такой запрос необходим по каким то причинам, то стоит посмотреть что же происходит с запросом. Нужно в первую очередь сделать отдельно вложенный запрос, проверить как он работает, оптимизировать, а затем то же самое сделать с внешним. Так же неплохо прогнать эти запросы через explain, посмотреть каких индексов не хватает. Ну и первое на что стоит обратить внимание это tt.taxonomy LIKE 'pa_%', что само по себе затратно, и требует обязательного индекса.