А если оно изначально имеет нулевые высоту и ширину, может и не надо его дисплей-нонить? Его же всё равно не видно, и место оно не занимает?
На мой взгляд, тут всё зависит от степени перспективы роста, и распределения нагрузки в течение суток. Под транзакциями вы очевидно подразумевали conqurency, то есть, возможность двум или более процессам писать в лог одновременно. И в этом, при больших нагрузках, при использовании файлов, может оказаться слабое звено. В отличие от базы данных, в файл два процесса не могут писать одновременно. Соответственно, они выстроятся в очередь, и будут друг друга задерживать, и на определённом этапе часть записей не будет производиться.
При использовании базы данных для логирования ошибок, следует учесть вот какой тонкий момент: недавно я столкнулся, в одном из наиболее распространённых скриптов форумов, велось логирование ошибок в базу данных. При большой загрузке сервера, начинают возникать ошибки, типа "Lost connection...". Скрипт пытался записать в лог об этой ошибке, что естественно вызывало ошибку, которую он вновь пытался записать в лог... В результате, за сутки error_log вырастал до много-сотен-мегабайтных размеров.
Хочу попросить автора, или кого-то из ответивших, если не трудно, объяснить мне суть вопроса.
Хочется предположить, что новости, в таблице новостей, распределены по категориям (новости про кино, про вино, и про пиво). Для этого в таблице новостей очевидно имеется внешний ключ, типа category_id. И требуется сначала показать <SELECT>, состоящий из названий категорий (кино, вино, пиво), а затем, когда посетитель выберет нужную категорию, показать ему новости, относящиеся к этой категории. Вопрос в этом?
В стандартном виндоусе 7, в комплект поставки входит программка "Ножницы" (Пуск/Все программы/Стандартные/Ножницы). Делает то, что написал WebJunior про SnagIt. В качестве документа (Ворд / не Ворд) я предпочитаю документы гугла (http://drive.google.com). Там вы имеете общий с дизайнером доступ к одному документу, где вы можете написать что-то, вставить скрин-шоты со стрелачками, а дизайнер там же (можно одновременно, в режиме он-лайн, так сказать) добавит свои стрелочки и комментарии. Очень удобно. Сохраняется вся история правок.
А в процессе работы на более продвинутых фазах очень удобна функция показа экрана собеседнику в скайпе.
Если вам скажут, что опасно выкладывать материалы в сеть (в документы гугла) - стразу бросьте в говорящего тухлый банан :)
По поводу выбора между учебником и видео-уроками: по способу восприятия люди делятся на дислексиков и гиперлексиков. Первым (их больше) материал понятнее, если им его рассказывают; вторым - если они его читают.
По поводу ООП, знаю что со мной тут многие не согласятся, но всё же хочу, чтобы это прозвучало: ООП, для построения сайтов, для которых интересующиеся здесь люди интересуются изучением РНР, ни в жисть, ни каким боком, не надо. ООП - это стиль программирования, имеющий ощутимые преимущества только при решении сложных задач, где требуется большое количество различных вычислений и логики. Прогноз погоды, расчёт движения космических тел, трёхмерное моделирование, и т.п.. РНР - это язык программирования, придуманный для того, чтобы просто, легко и быстро делать простые сайты. Только из-за того, что миллионы программистов, которым в институтах и колледжах искусственно привили любовь к ООП, пришли в РНР, и стали высказывать свою разочарованность отсутствием там ООП, оно было "притянуто туда за уши". На мой взгляд, оно там совершенно лишнее. И изучая РНР, ознакомиться с ООП нужно только в той степени, которая позволит понять уже написанную какими-то умниками в стиле ООП программу, если возникнет такая необходимость.
Тут уже как-то между строк звучала мысль, хочу её усилить: важно не знание языка, а умение программировать. Умея составлять программы, перейти с одного языка на другой - не составляет труда. Но для успешного программирования нужен определённый (технический) склад ума. Если он у вас есть - берите практически любой учебник, и начинайте программировать, выполняйте все примеры из учебника, и вы "встанете на рельсы". Если его у вас нет - лучше не тратьте силы, время, надежды... Всё равно не сможете нормально программировать, даже вызубрив все функции языка. У меня был друг, который несколько лет пытался осилить MySQL по учебнику (он решил начать с него), потом прошёл платный курс, но так и не может самостоятельно написать запрос, чуть сложнее самого простого. Причём он далеко не тупой. Но склад ума у него не технический, а коммерческий.
Что касается фреймворков - это вопрос скорее идеологический (сродни религиозному), чем технический. Кто-то верит в, и любит определённые фреймворки, кто-то верит в другие, кто-то не верит ни в какие, потому что ему и так хватает. Лично я отношусь к последним. Когда научитесь программировать, ознакомитесь с фреймворками, и примете для себя решение.
ТС, вы бы дали ссылку, где нашли, может там и объяснение есть. Непонятно зачем вот этот кусок:
* html #page { width:auto; padding-left: 800px; } * html #container2 { margin-left: -800px; position: relative; } * html #page, * html #container1, * html #container2{ height: 0; }
В остальном, как я понимаю, решение совпадает с предложенным товарищем sweb27.
Osya прав, это делается одним запросом, примерно таким образом:
SELECT t2.id, t2.inner_id, t2.shop_id, t2.model from table2 t2 JOIN table1 t1 ON t2.inner_id=t1.inner_offer_id AND t2.shop_id=t1.shop_id ORDER BY t1.shop_id DESC
Неправильно. Для навигации служат якоря (#) в адресной строке. А класс таргет служит для задания стилей для того элемента, id которого указан в данный момент в якоре в адресной строке. То есть, он позволяет, в дополнение к прокручиванию страницы к нужному элементу, ещё и выделить его стилями. Стили, в данном случае, могут быть скрывающие и показывающие, что и прекрасно продемонстрировано богоносцем в его примере. Вы бы попробовали, тогда сразу правильно поймёте.
