Алексей Уколов

https://github.com/ivolo/disposable-email-domains

Они так говорят, потому что:
1) Если вы везде используете JOIN то на большом проекте у вас перестаёт работать кеш встроенный в БД, т.к. insert или update хотя бы в одну из таблиц участниц join сбросит кеш всего запроса, а на больших проектах изменения данных идут постоянным потоком.
2) JOIN делает жётские связи на уровне данных, это хоронит возможность оптимизации на уровне архитектуры приложения. Когда таблицы не связанны внешними ключами и запросами то мы можем перенести любую таблицу, в другую БД оптимизированную для нужных типов запросов, написать например на Си отдельный сервис/демон для этих данных. При этом нам надо будет переписать только одну сущность в приложении. В случае с разрешёнными JOIN может выясниться что переписать надо вообще всё.
3) Существует популярный подход переваривания больших нагрузок/данных это шардинг, т.е. раскидывание диапазонов данных по разным серверам, это когда первые 10 миллионов записей лежат на одном сервере а вторые на другом, join в этом случае сделать нельзя.
4) Нормализация, полностью нормализованная БД самая медленна(т.к. куча JOIN, каждый из них это умножение двух матриц), но зато самая компактная, полностью не нормализованная БД самая быстрая (так как всё берём одним простым запросом), но очень жирная и неприемлемо сложная в работе.

Ваш пример очень абстрактен, если про него ясно только, что данных очень много и не известно кто и в каких условиях будет с этим работать, но скорость ответа важна, а количество запросов будет большими. (Например это API к которому сторонние люди будут писать приложения и потенциально рекламировать эти приложения по ТВ)
То например так:
1) Запросом c JOIN скормить данные этих двух таблиц в поисковый индекс на sphinxsearch
2) Делаем запрос с параметрами book.param = 1 AND author.param = 2 поисковому индексу сфинкса, он возвращает нам PK ID нужных сущностей
3) Делаем SELECT * FROM t WHERE id in(1,2,3..N)

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

Если поля, по которым производится JOIN, имеют индексы, то запрос будет идти гораздо быстрее, чем без них, так что нужно смотреть индивидуально. Если индексов нет, то в плане выполнения, скорее всего, будет FULL SCAN и итоговое время будет пропорционально произведению количества строк в двух соединяемых таблицах - O(M*N).

php.net/manual/ru/index.php
php.net/manual/ru/function.include.php
php.net/manual/ru/function.autoload.php
www.phptherightway.com

Я боюсь представить, каким местом вы пытаетесь питаться...

Я так понимаю, вы хотите общаться со скриптами на своем же сайте с помощью HTTP? Да вы редкостный извращенец, скажу я вам...

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

В Конструкторе карт можно получать карту в разрешении 300 dpi для печати. Поддерживается всё, что есть в самом конструкторе.
https://tech.yandex.ru/maps/tools/constructor/

1. Во-первых, вызывать повторно функцию лучше после успешного завершения ajax-запроса. Т.е. перенести setTimeout в "success callback ". И setInterval - не очень хорошее решение для данной задачи, как предлагали вам выше.
2. Во-вторых, повторный вызов функции, как это сделано у вас, ни к чему хорошему не приведет, т.к. вы не передаёте в функцию аргументы.
3. В-третьих, оглядываясь на п.2, непонятно, какие именно аргументы нужно передавать: то ли из предыдущего вызова, то ли необходимо повторно пробежаться по элементам "td[data-pll]", собрать из низ данные и передать в функцию.
Синтаксис для вызова функции с передачей ей параметров, может быть и таким:

setTimeout(func, delay, [param1, param2, ...]);
// т.е. в вашем случае:
setTimeout(F1, 5000, sname, cls);

table = fizz(table);

Что сделать-то хотел?
Если проинициализировать массив значением которое вернула fizz, нужно было просто проинициализировать его в этой функции.
Если поменять область памяти на которую указывает table, то нужно было сделать table указателем.

Почему при передаче table в fizz struct Item[100] преобразуется в struct Item *table, а при присваивании - нет?

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

"Эталонный" код отличается от неэталонного тем, что в течение своей жизни, при исправлениях и внедрении каких-либо новых функций, претерпевает минимум изменений, и эти изменения локальны - то есть правится не по 1 строчке в 10 разных местах, а 5-10 строчек в одном месте.

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

То, что вы написали тоже, конечно, имеет значение, но так абстрактно не рассудишь. Вот мне, к примеру, не нравится когда html мешают c js. Но с другой стороны на подобном подходе построен react.js, в котором этим пожертвовали в угоду идее компонентно-ориентированного подхода. И, по слухам, получилось неплохо.

Как можно оценить время на фичу из гита если у тебя есть только время пуша?