ThunderCat

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

У меня сейчас имеется одна таблица для одного поста.

Точно? Это на сайте будет один пост? Или под каждый пост будет таблица? Или все таки одна таблица для постов? (читать про нормальные формы бд, 1,2 и 3 НФ)

Но как лучше реализовать комментарии, чтобы была одна таблица, но там хранились комментарии из разных постов?

Очень просто: Таблица, где будет поле post_id, которое будет указывать на пост, к которому относится комментарий. Если структура иерархическая, то еще parent_id, указывающий на какой комментарий это ответ. (Читать про отношения Один-ко-многим, хотя и про остальные тоже для общего развития. Ну и про иерархические структуры через nested sets)

понимаете, если будет много комментов, то долго будет обрабатываться. =/

Понимаете, вы нихрена не разбираетесь в вопросе, но уже уверенно несете чушь про "будет долго обрабатываться", хотя точно этого не знаете (спойлер: не будет долго обрабатываться).

Просто через LEFT JOIN получается так что продукт дублируется столько раз сколько имеет соответствий с таблицей INFORMATION.

GROUP BY p.id
ORDER BY s.rating DESC i.int DESC

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

Во первых - где сама форма?
Во вторых - у полей есть айди, но нету имен, что за фигня?
в третьих - берете формдату из формы, и из энтиес делаете объект

const data = new FormData(formElement);
const value = Object.fromEntries(data.entries());
console.log(value);

1) У вас криво вставлена разметка, вы там теги штоле нормально расставьте
2) оба селекта имеют одинаковое имя: select name="profession"
3) В чем собсно проблема? Не нашли как отправить значения формы аяксом? (Результатов: примерно 1 120 000)

Или лучше всё-таки отучиться нормально и потом уже о заработке думать?

Первым делом нужно выделить направление. Иначе разброд и шатание сделает только хуже. Сегодня востребованы, как нынче модно говорить, T-shaped спецы, по этому с твоим, без преувеличения, обширным и полезным списком увлечений, все таки придется как-то выбрать чем конкретно ты хочешь заниматься и давить в одном направлении более интенсивно. Ну и пробовать искать работу под профиль. Образование можно получать заочно, это вполне норм и, я бы сказал, тренд.

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

Создаю свой мессенджер, задача такова что нужно сделать список абсолютно всех мелодий которые есть в мире, так же как в вк, как это можно реализовать?

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

1) Хранилище. По примерным оценкам в мире в цифровом виде около 500 000 000 оригинальных музыкальных композиций. Учитывая ремиксы и каверы - можно смело брать миллиард. Средний вес композиции среднего качества - 5 Мб. То есть порядка 5 петабайт, если хранить не в лучшем качестве. Учитывая что это должно иметь какое-то резервное хранение (у нас тут серьезный сервис все-таки), умножаем на 2 (10 петабайт). При стоимости около 2 центов за гиг в месяц, 10 000 000 Гб * $0,02 = $200 000 в месяц хранение. Ну, бюджетненько в целом.

2) БД, которая хранит данные обо всех этих композициях. Стоимость хранения будет поменьше, но думаю к 20-50К все равно где-то выйдет.

3) Другой вопрос - где брать эти данные, так как не все музыкальные файлы содержат полное описание композиции. На перебор 1 миллиарда записей и сортировки их по жанрам, альбомам, исполнителям, дате выпуска и т.д. уйдет некоторое время. Допустим 50% композиций будут иметь нормальное описание, остается все те же 500 миллионов композиций на обработку. Пусть на каждую понадобится 2 минуты работы, внести данные в поля (хотя их еще как-то найти надо, но допустим), тогда получим 1 миллиард минут. Это 1900 лет работы, или 16 666 667 часов. Час работы самого дешевого индуса - 3 бакса/час. 16 миллионов * 3 - давайте округлим до 45 миллионов. Даже если сократить этот пункт в 10 раз - выйдет под 4 миллиона. Рабский труд сегодня дорог как никогда...

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

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

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

По итогу на год:
$200 000 * 12 = $2 400 000 хранилище
$20 000 * 12 = $240 000 бд
$20 000 * 12 = $240 000 сервера приложения
$4 000 000 работы
Итого: чуть меньше 7 миллионов баксов.

(Ошибка в foreach)

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

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

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

запрос Гугл laravel Результатов: примерно 44 600 000 (0,78 сек.)
еще вопросы?

Сразу видно несколько проблем:
1) У таблицы нет индекса (2 нф), возможно это пока только представление в экселе, но надо учесть.
2) Очевидно что таблица имеет тенденцию к расширению по столбцам, что, очевидно, плохо.
3) п.2 в том числе образуется из-за смешивания сущностей в одной таблице, которые нужно разнести по рзным таблицам и связывать пивот таблицами (3 нф).

Вообще вам больше и точнее подойдет Нормальная форма Бойса-Кодда, хорошо и просто описанная здесь.

Если не умеете в программирование - го в гугл.

https://www.google.ru/search?q=get+all+links+from+site

например https://chrome.google.com/webstore/detail/link-kli...

Если известны имена таблиц - юнион. Если не известны - никак, или через извращения типа регулярки с выборкой из схемы.

Сайт подгружает с помощью ajax.

Ну так ищете на какой урл (и каким методом) отправляется аякс запрос, повторяете у себя такой же - профит.

1) для начала проверить что что-то вообще работает, тупо передать руками созданный объект из 1-2 строк.
2) Сколько записей в comments? может их там 5 миллионов и он все пытается передать на фронт? Вообще запрос без условий, лимитов и сортировки выглядит весьма странно...
3) Смотреть консоль, что вернулось, что пишет нетворк - статус, тело ответа.
Короче стандартная отладка, ничего нового.