Дмитрий Энтелис

два варианта:
1. присваиваем файлам длинные, сложно подбираемые пути/названия.
плюс: очень быстро работает, нет дополнительной нагрузки на сервер
минус: у картинки есть общедоступный url который может быть скомпрометирован

2. кладем файлы в недоступную снаружи папку, доступ к ним идет через скрипт проверяющий авторизацию пользователя
плюсы и минусы соответственно наоборот.

Ладно вам, понятно же что не родной язык у человека.

По теме: пересмотреть портфолио. Половина заказчиков когда увидит joxi.ru/RmzXBe8f0E8y1A развернется и уйдет.
Выложить проекты на какой-то нормальный домен, это не дорого.

Если продаете себя как верстальщика - не нужно писать что Вы широкий специалист.
Откликайтесь конкретно на верстку.

Судя по сайту - с английским у Вас лучше чем с русским, но возможно стоит пересмотреть cover letter тоже.
Если на русско-язычном фрилансе - 100% нужно что-то делать.

90k записей в месяц? 500 групп. 45 000 000 записей?
Да что угодно, от обычного MySQL, до модного ClickHouse.
Монгу - ну пощупайте, но мне кажется с производительностью там все плохо на самом деле.

1. В маленькие - как повезет, зависит от личного отношения владельца. В большие - без шансов.
Абсолютно все энтерпрайз компании формализируют и бюрократизируют бизнес-процессы, - и проверка СБ является обязательным пунктом. Никакие друзья в компании обойти это не помогут - т.к мгновенно вылетят следом за попытку.

2. 228ч2 - чуваку до 10 лет отсидки грозит, какая условка. Ему не о карьере сейчас думать нужно, а о том как не присесть.

Самое главное что нужно учесть в это задаче - если это живые обновляемые данные, то получение и обновление должны находиться в рамках одной транзакции.
Делая SELECT * FROM `table`, а потом обновляя записи в цикле - вы имеете огромные шансы что за это время другой поток как-то обновит таблицу, и ваш код вставит старое значение.

Ну и я лично не стал бы городить класс Improve ради разовой задачи, это проще все описать в функции.

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

Таблица врачей - ок.
Таблица категорий - ок.

В реальном мире связь между ними many2many.

Дальше тоньше.
Я бы делал слоты для записи отдельной таблицей, в которую писал datetime начала и datetime окончания слота.
Слоты генерим кроном на N суток вперед.

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

Ну и соответственно отдельная таблица для талонов.

Связь между слотами и талонами many2one, т.к талоны в реальности могут отменяться итд.

я уже ответил что нет Можно ли журналирование действий пользователя реализовать на front-end?

зачем создавать дубли вопросов??

Нет, не правильно.
Фронт не должен содержать в себе бизнес-логику.
Хотя бы по той причине что любой запрос фронта могут заблокировать или видоизменить.

1. учимся дебажить.
если что-то не работает, нужно по шагам проверить все.
что передается в каждую функцию.
что возвращается из каждой функции.

2. перестаем использовать mysql_, переходим на mysqli_ / pdo

3. обновляем версию PHP до актуальной

PS
ответ на вопрос - потому что внутри функции не определен $all_about_user_array['id'].
его нужно туда передать агргументом

PPS
Вместо

mysql_query("SELECT `api_key` FROM `users` WHERE `id`='$all_about_user_array[id]' LIMIT 1");

пишите хотя бы

mysql_query('SELECT `api_key` FROM `users` WHERE `id` = ' . (int)$all_about_user_array[id] . ' LIMIT 1');

Любого заказчика в первую очередь интересуют 2 вещи:
a) сколько ресурсов ему потребуется на проект?
b) почему именно столько?

Общий подход - декомпозировать задачи указанные в тз.
До какого уровня - зависит от конкретного заказчика и размеров проекта.
Моя субъективная точка зрения - на стадии продажи нужно декомпозировать условный средний проект до 30-60 задач.
Больше - слишком накладно, меньше - слишком большие погрешности.
Но опять же, это мой опыт и мои типовые проекты.
Если кто-то ERP системы пишет - там и 500 строк в оценке не много.

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

PS В целом InoMono написал правильно.
Заказная разработка как бизнес практически не масштабируется горизонтально.
Хорошие менеджеры хотят очень много денег, а большая команда разработки быстро съедает всю прибыль при малейшем простое.
Выход - только вертикальное масштабирование.

PPS посмотрите еще Стоит ли основать веб-студию?

UPD

Чтобы работало системно, нельзя подходить из серии - пробуйте продавать максимально насколько лично получится

- ваши слова.

Как это делается системно - я написал выше.
Как это делается не системно - написал InoMono
В чем вопрос то?

По какой формуле считать так, чтобы было понятно и прозрачно для заказчика?

Заказчику понятно когда вместо "я сделаю вам сайт за 200 часов" ему присылают (все цифры условно):

• составление тз 20
  
• согласование тз 5
  
• скетч дизайна 120
  
• определение фирменного стиля 80
  
• дизайн на основе скетча и фирменного стиля 60
  
• верстка html 40
  

по желанию крупные блоки тоже расписываются, вместо "верстка html 40" - верстка каркаса, верстка главной страницы, верстка страницы X...

Или вопрос "какая норма доходности"? У всех по разному. от двухзначных до пятизначных цифр.

Я больше беспокоюсь о том, что пользователь может прямо в консоли отправить запрос на перезапись данных.

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

1. Срок давности по налоговым преступлениям 3 года.
У вас за этот срок набежит 200k * 3 = 600k оборота.
Налоговая влепит:
20% = 120k штраф
и (внимание) проведет доначисление налогов по своему усмотрению, как если бы у вас было юрлицо: исходя из обязательных взносов в фонды, это еще примерно 50% от исходной суммы = ~300k.
Итого вы легко набираете ущерб государству свыше 250к - со всеми прелестями уголовного наказания и дополнительного штрафа в рамках него.

2. В стране в целом закручивают гайки на тему налоговой дисциплины и противодействия отмыванию.
Даже для сумм в 100-200 т.р могут потребовать обоснование их происхождения.
Презумпция невиновности не работает.

3. Исходя из вышесказанного - советую всем отметившимся тут (@InoMono Padre Валентин ) не создавать себе проблемы на ровном месте, а открыть ИП. 6% с оборота, 1-2% за вывод в кеш - и вы полностью чисты перед государством.
Бухгалтерию можно вести в любом модном онлайн сервисе, отчетность сдается одной кнопкой раз в год.
Помните где вы живете.

Да ладно вам, простой запрос же.

select
	films.*
from meta
left join films on films.id = meta.id_films
where meta_value in (13,15,27)
group by id_films
having count(meta.id) = 3

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

Если нужен не четкий поиск, можно например сделать вот так:

select
	films.*,
	count(meta.id) as cnt
from meta
left join films on films.id = meta.id_films
where meta_value in (13,15,27)
group by id_films

и дальше показывать юзеру по убыванию cnt

Мне кажется что парсить сайт по внешним ссылкам - это ну очень ресурсоемко и криво.
Логично генерить sitemap путем хардкода структуры сайта/запросов в базу, заодно можно корректно заполнять поля lastmod, changefreq итд.

Если необходимое количество знаков после запятой может меняться - то DECIMAL с указанной точностью + обязательно использовать для математики какую-нибудь либу которая умеет в точность, в противном случае результат Вас может жестко огорчить

$a = 5.2 * 3;
$a = $a - 15.6;
echo ''.$a; // выводит 1.7763568394003E-15

https://3v4l.org/NnLTF

Альтернативное решение: если точность везде фиксирована, а сами цифры не очень большие - храните в integer/big integer и при выводе делите на нужное число.