Я бы рекомендовал купить ближе, что бы уменьшить стоимость доставки (в Украину было ближе в Германии/Италия).
ЗЫ:
Покупайте сервера по легче = тоже экономия)))
Я когда-то почти 55-ти килограммовый 4U сервак из Германии на дом заказал, потом в поезд вдвоём заносили - еще та веселуха была. Чуть-чуть и могли не пустить в поезд😂 Сам сервак стоил 29 евро в Германии, но потом... 🍿
Я всё же не пойму для чего? - вот вопрос полность: /ru/forum/comment/9315760
по +1 за каждое предложение
Некоторые и без поисковиков живут)))
Хм...Вопрос не в бровь, а в глаз: зачем? То есть какие цели преследуются?
Так и не понял - цель посещаемость?
И готовы ли Вы к последствиям?☝
Увеличение посещаемости = увеличение нагрузки != увеличение прибыли )))
Если (зная себя) до кучи захотите заниматься солнечными батареями через пол года, а потом еще басейнами, потом кафелем, а потом вообще промышленной техникой для клиринга - то отдельные сайты.
А так лучше качественный контент + брендирование магазина.
Нужно делать то, что согласуется с вашим проектом.
Минус в том, что на коменты не повлияешь
Плюс в том, что милиция будет обращаться не к вам с целью раскрытия личности комментатора, а к соц.сети))
http://vkontakte.ru/developers.php / http://vk.com/developers.php
Выбираем http://vk.com/editapp?act=create&site=1
А дальше вам в вашей CMS надо указать id например 77777777777777777 и на вашем сайте будет примерно такое
Готовое вы не интегрируете, либо сложно будет - легче написать)))
На действие "регистрация пользователя" добавить action "создание инвайта(ов)".
На действие "level up" добавить action "увеличение количества инвайта(ов)".
Один из вариантов:
Я бы создал таблицу: invates с 3-мя полями: invite - ключ (сам код инвайта - лучше цифровой), uid_user (ид пользователя, который приглашает), uid_invited_user (ид пользователя, который ввел инвайт).
В этом случае Мы наполняем таблицу записями для пользователя с его инвайтами, когда кто-то вводит инвайт Мы вносим в uid_invited_user ид нового пользователя - всё, больше инвайтом пользоваться никто не может.
Минусы:
*Если у Вас 100 000 пользователей * 5 инвайтов, да плюс 5 инвайтов на уровень = 1мульйон записей, что заставит базу пыхтеть
Обход:
*Удалять уже выданные
*Выдавать инвайты по требованию, но тогда надо знать как рассчитываются инвайты (максимальное количество) и в одной из таблиц хранить оставшееся количество (но не обязательно)
Плюсы:
Легко внедрить и при правильном использовании можно не париться
При правильной разработке нужно писать для разрабатываемых прог тесты.
Года 3-и назад Я писал внутрилокальный портал с фильмами/музыкой/играми. И вот Я организовал поиск, который вешал базу))) Обнаружилось когда было всего 1000 обьектов в базе. Переделал схему базы, подкинул sphinx и все стало ок ;)
А если бы сразу по уму сделал с тестами, то и не выглядел Я так глупо)))
Да скрипт работает, но почему надо заморачиваться с тем, что бы ссылку?
Не ужеле сложно было регуляркой взять из кода ссылку + размеры?:
