Владимир Грабко: если вы внимательно посмотрите на конфигурацию указанную в вопросе и почитаете комментарии , вопросы отпадут сами собой. В таких системах обычно идут по 2 БП по 800 - 1000 ватт, плюс у человека комната с кондеем предполагается, а не подвал.
нет, совершенно необязательно, думаю вам неплохо было бы хоть немного подучить php перед работой. Посмотрите как работает форич в пхп, в документации довольно просто описано.
SKRSKR: ну что, пробуйте, особых проблем не должно быть, у меня дома стоял сервер на фряхе и пентиум II в свое время, в локалку раздавал инет и хостил внутренний сайт, я тогда много чего выучил ), в этом плане практически бесценный опыт. А с электричеством - я бы на вашем месте все же посчитал расход, у меня серьезно капало за свет, ну для сервера который не приносил денег.
дизайнер != художник нифига ниразу. И вот если понадобится фото "маленький ребенок рвущий пачку долларов" есть вероятность найти его на стоке, а не искать фотоаппарат, ребенка, пачку долларов, съемочное место итд.
Stasgar: Все очень просто, сегодня стандартом де факто является паттерн MVC, в котором все очень четко разделено, всем компонентам раздаются свои четко заданные роли, что есть очень удобно, при изменении или замене какого-либо компонента вся основная структура никак не поменяется, т.е. не придется переписывать пол проекта если внезапно шеф решил перейти с MSSql на MongoDB, меняется только класс доступа к бд(это как раз относится к теме абстракции! Все классы наследующиеся от BDAbstract будут работать с базой такими же методами как и до смены базы, остальные объекты этого просто не заметят). По поводу "основной php" - гуглите единая точка входа, это тоже из MVC.
Stasgar: а чем не причина? Это унификация обращения, и инкапсуляция, я знаю что делает Васин метод, но мне пофиг как он реализован, я знаю что он там есть из наследования абстракции.
thekot24: разве это критерий делать/не делать? Во первых - это современно, во вторых mysql функции депрекатед, в третьих - вы же просили совета у людей - вам советуют, там и отладка нормальная, и завтра работать не перестанет. Да и кроме того - все остальное сделайте, никто вам ничего не навязывает же. Скорее всего как все выполните найдете свой баг за пару минут.
Ivan Yakushenko: вы прочитайте статью хотя бы, если уж документайию сложно. Вы создаете ЕДИНЫЙ ключ для всех полей, значит либо указывайте все поля включенные в индекс и поиск будет во всех полях, либо создавайте отдельные ключи на поля.
Ivan Yakushenko: сделайте экспорт структуры таблицы и посмотрите какие поля у вас входят в FTS. Тыкать в "создать индекс" в пхпмайадмин не лучший способ создания индекса, кроме того нифига не гарантирует.
lightalex: зачем плодить сущности, если есть уже изображения у пользователя? добавьте поле is_avatar и радуйтесь тому что не приходится работать с еще 1 видом объектов. вы все равно будете получать пользователя из базы, если при этом еще будет джойниться табличка с картинками на предмет аватарки - сильно нагрузка не возрастет, количество запросов не увеличится и все будет работать правильно, по уму, и без неучтенных файлов. Имхо только плюсы.
lightalex: я конечно не знаю какой у вас объем дискового пространства, но если файлы у вас только аватарки - какие нагрузки? какое место? файлы по 20кб? Кроме того - наличие записи в базе я считаю обязательным, иначе у вас будет бардак - есть у юзера аватар или нету через наличие файла в папке не определяют, это лишнее телодвижение. Если завтра в папке будет дохринилион файлов и вы задумаетесь о том что неплохо было бы разложить их отдельно по какой-то логике - вот тут вы и будете рыдать над осколками своего счастья ) Ибо все должно быть учтено. Желательно в бд. А завтра у него появятся еще и фоточки в альбомчиках - вообще полный конец обеда будет! Так что храните деньги в банке.. ну в смысле пути в базе.
