SELECT COUNT(*) AS _count, user_ip FROM my_table GROUP BY user_ip ORDER BY _count DESC
Можно такой вариант попробовать, если правильно задачу понял.
Ну в штатах довольно много перешло на "экологические" варианты, по крайней мере в прайсе встречаются часто. Обычно это экономичные модели, менее производительные, но не из старых компонентов от БУ компов.
Так что если хостер смеется над понятием "green server" , то он как бы в пролете от текущей ситуации в хостинге :)
искать конверторы для базы. Если их нет, то написать конвертор самому или же заплатить за его написание.
100 к 100 естественно сконвертировано не будет, но рабочий вариант будет.
не красиво домашние задания перекладывать на чужие плечи :)
есть 10 автомобилей, есть бассейн - как их там запарковать, неужели никто не знает ? :)
Ну вносите резюме как страницу, в чем проблема то ? Собственно как и машины в бассейн укладывать, что бы паркинг был.
Хотите нормальный сайт с резюме - пишите отдельный движок по своему ТЗ.
Работают, не спорю. Но там по сути реализовывают свою БД, храня в отдельных файлах привязки записей.
Попробуйте прочитать 1000 файлов на поиск подстроки или какой либо другой операции, а потом сравните то же самое с sql запросом в базу. И посмотрите как хард будет себя вести в первом случае, а как во втором.
В базе данных не хранятся страницы, в ней хранится только информация. И удачи вам в создании странички с заметками от пользователя Васи по тематике "Рыбалка".
Что а базе будет сделано 1 запросом, то у вас с 100500 файлов будет не возможно, ну или же вы просто убъете дисковую систему своим рекурсивным открытием/закрытием этих 100500 файлов, в поиске "а где же Вася писал с тегом рыбалка".
Zend. Так же наблюдается массовая миграция на Yii.
CVS/SVN системы контроля, вторая более удобная, имхо.
Никак. Пишется патч с инструкциями для базы, загоняется в движок сайта, сайт сам должен его подхватить и выполнить. Грубо говоря, должна быть реализована система апдейтов в движке.
Программисты сидят рядом - если да, то поможет кофе, печенье и шоколадки.
Багтрекер нужен простой, обычно что бы туда менеджерами и прочим составом вносились ошибки. Идеал, если эти ошибки можно вносить непосредственно с админки сайта, так сказать по горячим следам.
Ничего не мешает. Он может вообще клиента отключить и управлять сайтом сам, так даже легче. Но зачем ? Без посторонних действий, хостер доступ в админку скрипта не получит, а в нормально защищенный скрипт и вообще доступ не получит. Это ведь сразу видно, левые пользователи или измененные пароли у админов.
Хостер может конечно иметь доступ к сайтам клиента, но не к админкам CMS движков. А поскольку у вас там сайты "организации", то и ищите в ней того, кто это делает, вспоминайте кто еще доступ имеет.
А то ситуация схожа с "управдом ночами ходит по квартирам жильцов и обои переклеивает".
