FanatPHP

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

Для компьютера и число и строка - это набор байт. Что конкретно в эти байты записано - ему всё равно. Поиск по упорядоченному набору байт будет производиться одинаково.

Не стоит заранее переживать за производительность. От этого одни проблемы.

Скорее всего тормоза из-за дефолтных настроек движка InnoDB. Надо либо завернуть все запросы в транзакцию, либо сделать одним запросом, например так:

AND number = IN (....все номера...)

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

А вот подход с разделением на хидер и футер - неправильный и давно устарел.

Делить страницу надо не на хидер и футер, а на код и отображение. Потому что:

- во-первых, отдельно хидер и футер редактировать неудобно.
- во-вторых, иногда нам надо выполнить некоторый код ДО вызова хидера.
- в-третьих, у "середины" тоже должен быть свой шаблон - о чем многие начинающие разработчики забывают

В итоге страница должна собираться из трех частей:

1. Логика приложения. Должна выполняться ДО любого вывода, и хидера в том числе.
2. Общий шаблон сайта, который содержит в себе и хидер и футер. Вызывается после того, как отработала логика.
3. Шаблон конкретной страницы, который включается в общий шаблон сайта.

При такой структуре не составит никакого труда вместо страницы вывести сообщение об ошибке (при ошибке) или поменять формат вывода с HTML на JSON. Не говоря уже о смене дизайна.

Вариантов реализации может быть масса, пример самой простой, на чистом PHP, можно посмотреть здесь: http://www.phpfaq.ru/tpl#example

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

Соответственно, разумная организация представляется мне такой
1. Разработчик разрабатывает на своей локальной машине. Именно разрабатывает — пишет, запускает, отлаживает. Разработанное заливает в Git
2. На devel-сервере реализовано динамическое создание поддоменов. Создал девел папку t12 в /opt/www/bob — автоматически появился сайт t12.bob.devel.mysite.com.
3. Делаем в этой папке git clone (или pull) — и таким образом обновляем код.

Сферический вопрос в вакууме, причём без возможности уточнения, поскольку «проект был».
«медленные запросы» — насколько медленные?
«сайт с посещаемостью» — с какой посещаемостью?
«потому что запросы на поиск» — так может, это поиск вынести отдельно на Сфинкс?

То есть, выяснить, что там — кривая настройка сервера mysql, кивые таблицы или кривые запросы — не представляется возможным.
Но вопрос, как всегда, формируется в самом общем виде — «где тот волшебный гвоздь, по которому 1 раз ударить — и всё сразу залетает?»

Ну ок. В самом общем виде оптимизация запросов (неважно — частых или нечастых) заключается в оптимизации запросов.
Оптимизированный запрос выполняется (допустим) 0.001 секунды. То есть, БД может обслужить 60 тысяч одновременно сидящих пользователей.

Берем EXPLAIN и смотрим. Если он говорит, что с запросом все окей, просматриваем ровно столько записей, сколько нужно — 5-10, но все равно запрос исполняется медленно (насколько конкретно медленно — в секундах?) то смотрим, SHOW ENGINE [engine] STATUS. Там уже надо опять же смотреть по месту, решать, чего серверу не хватает.

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

То есть, действуем как программист — а именно, разбираемся с конкретной проблемой, и ищем решение конкретно для неё.
А не придумываем от балды заплатку для лечения симптома, оставляя болезнь развиваться и дальше.

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

Вообще-то есть такая штука, как open_basedir, которая делает именно это.
Но как-то не кажется мне такая идея 100%-й защитой.

Ошибка, действительно, древняя, как экскремент мамонта. Объясняется здесь.
То есть, если есть переменная, допустим, $_SESSION['user'], имеющая значение NULL, и тут мы присваиваем какое-нибудь значение переменной $user — вот тут ошибка и вылезает.

Легко отключается через

ini_set('session.bug_compat_warn', 0);

Но лучше всё-таки проапгрейдиться. Тем более, что начиная с 5.4 пхп будет уже ругаться на эту настройку, как несуществующую.

В первом варианте ничего «обычного» нет. Это вообще не вариант.
Если у нас действительно key-value хранилище, без вложенности и древовидности, то вполне подойдет второй.
Проблем с «контролем на чтение-запись» никаких не вижу. Уникальный ключ на юзер_айди-парам_айди должен решить все проблемы.

А вот если система должна поддерживать иерархию — к примеру, категория «хобби», к которой могут относиться сотни различных занятий — то как раз предложенная выше Монга и объединяет в себе эти два, на первый взгляд, противоречивые требования — хранение в JSON плюс выборки и сортировки.

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

По-моему, там довольно ясно написано.
Если планируем использовать или писать DBAL для работы с Mysql — то mysqli.
Если от привычки обращаться напрямую к функциям API избавиться никак не получается — то только PDO, поскольку эта библиотека частично реализует функции DBAL, а большая часть тонкостей, реализованных в mysqli, разработчику никогда в жизни не понадобится.

На первые несколько пунктов попробую написать рекомендации в свободной форме.


Первое и самое главное — чтобы хорошо изучить программирование на РНР, надо хорошо изучить программирование. Это очень важная вещь. Большая часть людей, пишущих на РНР, не имеют ни малейшего представления о программировании. Даже о таких базовых вещах, как форматирование кода, отладка, профайлинг, обработка ошибок, файловые операции. Можно заметить, что я не говорю об ООП. Это совсем отдельная тема, ООП надо учить специально. К сожалению, из 100 человек, которые говорят, что знают ООП, 90 являются банальными копипастерами, выучившими синтаксис, но не понимающими смысла объектов. Но чтобы играть в шахматы, недостаточно знать, как ходят фигуры.


Ещё неплохо бы ответить себе на вопрос — для чего ты хочешь выучить программирование на РНР? Вопрос совсем не праздный. Многие люди смешивают в нем кучу разных понятий. К примеру, здесь уже упоминали CMS. и действительно, если речь идёт о зарабатывании денег, то кастомизация Джюмлы и написание к ней говномодулей в финансовом плане куда более выгодны, чем умение писать что-либо с нуля. Для фриланса, во всяком случае.

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

• Можно склепать гостевую или сайт-визитку на «голом» РНР — и ничего плохого или позорного в этом нет. Наоборот — это плюс языка, который годится и для таких целей, не таща за собой пару миллионов строк кода ради сайта из пятисот.
  
• Можно написать профессиональный портал, взяв за основу какой-то из существующих фреймворков, и заниматься его развитием.
  
• Можно написать кастомный хайлоад проект, для которого нужно будет писать собственный фреймворк опять на голом РНР.
  
• Можно, как уже говорилось, клепать сайты на основе какой-нибудь ЦМС.
  

Вариантов масса! поэтому нужно определиться сначала, чего хочется.


Там выше говорили про JS+CSS — не надо слушать, это полная ерунда. Фронтенд программирование — совсем отдельная вещь, куда больше визуальная, чем абстрактная. И, слава богу, все больше работодателей начинают понимать это. Хотя опять же — если фрилансишь и на все руки мастер — то без этого никуда.

Но если работать хардкорным серверным программистом в команде, то об HTML/JS/CSS нужно иметь только общее представление (поскольку тексты на этих языках являются, вообще-то, практически единственным результатом работы РНР).


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


Теперь по остальным

Mysql всё ещё является краеугольным камнем хранения данных в вебе. Нужно знать и понимать джойны, индексы

Фреймворки — обязательно. Тут, правда, стоит проблема выбора, но принципиальной разницы между ними нет. Yii — неплохой выбор.

Гитхаб тебе не нужен, знать его не обязательно. Знать надо git.
А вот что является обязательным для веб-программиста — это умение пользоваться гуглем. Хотя бы на уровне умения скопипастить в поисковую форму сообщение об ошибке или написать вопрос «Что такое git» ;-)

Потому что для работы в команде какую-либо систему контроля версий знать надо, а git является стандартом де-факто. Понимать принцип работы и базовые команды — чекаут, коммит, пуш.

Вам не нужно никакое кэширование.
Вам нужно оптимизировать свои запросы.
«100 договоров и больше» — смешная цифра. По такому количеству любые выборки должны считаться предельно быстро, в сотые доли секунд.
Даже если тупо выбирать все сто договоров в скрипт и считать руками.

Кэширование должно применяться только после того, как оптимизированы запросы.
А сейчас вы пытаетесь поставить турбонаддув на машину, не сняв её с ручника.

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

Если не планируется использовать серверные плейсхолдеры, то тогда я вообще не вижу смысла использовать встроенный парсер ПДО.
Пишем свой и имеем
а) кучу дополнительных плейсхолдеров
б) возможность подставлять плейсхолдер в кусок запроса, а не только в целый
в) отладочный вывод.

А можно ссылку на закрытый вопрос?