Запросы ОЧЕНЬ зависят от ситуации. Есть конторы, где вообще запрещено использовать джоины (SpyLog меня когда-то этим удивил). Иногда действительно лучше разделить запрос на два и более, а связать уже в коде. Однако, повторюсь, это очень обширный вопрос.
Про смарти вспоминается фраза «вы просто не умеет их готовить». Заметьте, я не сторонник смарти, и даже кое в чем противник. Но тем не менее с вашей формулировкой я не согласен.
Знать — нужно. Я так и написал. Но не использовать Денвер нелогично. Он идеально подходит, когда вам надо за вечер слабать сайт-визитку, а среды на компе почему-то нет. Вобщем, как и всегда, все зависит от условий.
либо писать так, чтоб ошибки просто не могло возникнуть.
Простое правило, которое может здорово облегчить жизнь — используйте приведение типов.
«SELECT * FROM table WHERE id='.(int) $var — спасет независимо от того, что вы умудрились положить в var.
Это не избавляет от необходимости думать, но это надежный последний рубеж.
Вот про 22 полностью согласен. Даже тут на Хабре не раз уже появлялись топики на тему такой «оптимизации». В 99% случаев это бесполезная трата времени.
А вот с 2-м пунктом я бы поспорил. В серьезных проектах вам никто и никогда не даст настраивать среду исполнения — для этого есть админы. Это не значит, что вы не должны знать стандартные настройки (те же многострадальные глобалсы), однако уметь это все ставить и грамотно настраивать — не обязательный навык. Разработка в Денвере вполне неплоха, и, я бы сказал, рекомендована (если у вас нет тестового сервера конечно), если вы пишете «сайт фирмы» или что-то подобное.
Да, еще замечанице. Это отличная теория, но, как всегда, на практике иногда бывает все не так просто :)
Возьмем ваш пример избранных песен. Пусть у меня 100 песен в избранном и я хочу посмотреть этот список. Тогда сначала пойдет запрос в кеш на лист… а потом 100 запросов в кеш на песни. Иногда такое неприемлемо (например этот список не мой, а общий, и он висит на главной). Иногда рациональней закешировать все и сразу, пожертвовав атомарностью. Просто делать это надо аккуратно и с умом :)
ну только надо понимать, что для связей далеко не всегда нужна отдельная таблица. Только лишь в случае «многие ко многим». Это базовый курс.
Статья неплохая, но для начального уровня довольно скомканая, а для продвинутых уж больно базовая. Предлагаю немного детализировать и оформить как основы кеширования на средних и больших проектах.
ЗЫ: А масштабирование базы надо делать заранее. Чтоб потом не кодить с пеной у рта. Так что начинайте прям сейчас ;)
Ничем, вобщем-то, не отличается. А в предложенном способе не хватает удаления сгенеренного контента, к которому не было обращений н-ное время. Иначе место на сервере будет расходоваться нерационально.
Запросы ОЧЕНЬ зависят от ситуации. Есть конторы, где вообще запрещено использовать джоины (SpyLog меня когда-то этим удивил). Иногда действительно лучше разделить запрос на два и более, а связать уже в коде. Однако, повторюсь, это очень обширный вопрос.
Про смарти вспоминается фраза «вы просто не умеет их готовить». Заметьте, я не сторонник смарти, и даже кое в чем противник. Но тем не менее с вашей формулировкой я не согласен.
Простое правило, которое может здорово облегчить жизнь — используйте приведение типов.
«SELECT * FROM table WHERE id='.(int) $var — спасет независимо от того, что вы умудрились положить в var.
Это не избавляет от необходимости думать, но это надежный последний рубеж.
А вот с 2-м пунктом я бы поспорил. В серьезных проектах вам никто и никогда не даст настраивать среду исполнения — для этого есть админы. Это не значит, что вы не должны знать стандартные настройки (те же многострадальные глобалсы), однако уметь это все ставить и грамотно настраивать — не обязательный навык. Разработка в Денвере вполне неплоха, и, я бы сказал, рекомендована (если у вас нет тестового сервера конечно), если вы пишете «сайт фирмы» или что-то подобное.
Возьмем ваш пример избранных песен. Пусть у меня 100 песен в избранном и я хочу посмотреть этот список. Тогда сначала пойдет запрос в кеш на лист… а потом 100 запросов в кеш на песни. Иногда такое неприемлемо (например этот список не мой, а общий, и он висит на главной). Иногда рациональней закешировать все и сразу, пожертвовав атомарностью. Просто делать это надо аккуратно и с умом :)
Статья неплохая, но для начального уровня довольно скомканая, а для продвинутых уж больно базовая. Предлагаю немного детализировать и оформить как основы кеширования на средних и больших проектах.
ЗЫ: А масштабирование базы надо делать заранее. Чтоб потом не кодить с пеной у рта. Так что начинайте прям сейчас ;)