Сейчас я у мастерхоста на одном проекте использую VPS — плачу:
(+) тарифный план «Virtuozzo VPS Basic» 18 360 руб. (1 год)
Не сказал бы, что это навороченный впс. Более менее подходит для сайтов с посещаемостью 3 — 6 тыч в сутки.
тарифный план «Virtuozzo VPS Basic» 32 640 руб. (2 год)
18 тыч это дорого для VPS. — по сути издержек то особых для компании нет. Нарезали виешек и всё. Технической поддержки особо нету. Самому надо настраивать dns, почтовый сервер и прочее. Кроме апача и мускула по умолчанию ничего нет для старта работы.
В этом случае действительно выгодно купить железо — опять же настроить самому но потом платить только за аренду — финансово будет выгодно.
Если по стоимости будет дешевле, то есть смысл купить, так как преимущества в сторону железа. В случае с VPS наиболее большие минусы.
1. — Перезагрузка сервера зачастую без уведомления.
2. — Падение на 2-3 часа без понятных причин.
3. + Одноразовые вложения и далее только оплата аренды стойки.
При покупке VPS в год средняя цена более менее 30-50 тыч обходится. Интересно, какова его будет цена — будет ли входить в пределы 30 тыч? Если да — то однозначно лучше виртуализации до тех пор пока не произойдёт падение цен. Всё таки VPS сейчас довольно дороговат в России. И качество далеко не хорошее.
/*
Компания по перерегистрации ООО стартует в 2009 году, и должна быть завершена до 1 января 2010 года, что не представляется реальным для таких экономически активных регионов, как например Москва и Санкт-Петербург. По нашему мнению, перерегистрация ООО будет продлена до 1 июля 2010 года как минимум
*/
То есть проскальзывает мысль — а вдруг продлят. Ох как не хочется этим заниматься :-)
В данном случае происходит трижды запрос например со стороны php (хостинг пакупной — многое урезано в mysql — хранимки например — где это можно было бы завернуть в хранимку). Время вызванное этими отдельными запросами даст всё равно выйгрышь в производительности?
Хранимые процедуры не сильно облегчат возникшую у вас проблему, а если хостинг ещё и покупной, то про хранимки можно забыть. Я лично стараюсь избегать рекурсии следующим образом:
Допустим есть список категория следующего вида:
Id
parentId
Есть товар который имеет Id категории. Необходимо, по какой то выбранной категории выводить товары всех подкатегорий. Решение очевидно – рекурсия на стороне php или mysql. Это можно обойти если использовать дополнительную колонку в таблице категорий которая имеет в своём значении перечень всех подкатегорий по отдельной категории, то есть:
Id
parentId
childIds // 10,12,23,19
То есть необходимо однажды выполнить рекурсивный запрос для поиска всех Id подкатегория по конкретной категории и сохранить. Дальше просто. Изначальная проблема решается 2-мя запросами. Первым достаём значение childs, вторым получаем все товары
Select childsId from category where Id=10;
Select * from product where category id in (childsId);
Мне в смарти доставляет удовольствие его способность кешировать. Объявил какой либо шаблон, что наполняется данными, закешировал и всё база не вызывается лишний раз. Правда в одном из моих проектов таким способом бывает накешируется до 50 — 60 мегабайт (2 000 — 3 000 файлов), не знаю при поиске шаблона из такого колличества файлов — что быстрее — запрос к базе или же перебор смарти при поиске закешированного шаблона.
Мне кажется, что вместо абрактного класса следует использовать интерфейс, поскольку все классы наследующие интерфейс должны обязательно реализовать описанные методы в интерфейсе. Что даёт гарант того, что класс нельзя будет использовать до тех пор, пока он не будет готов хотя бы с методами заглушками.
на днях пользуясь phpmyadmin написал запрос на удаление определённых записей и надо же было тому случиться что вверху над запросом была кнопка drop. что произошло понял после е того как мне вывалился алёрт — table такой то was success dropped. Хорошо что пакаб был и в течении 3-х часов воставновил работу. Хочу сказать что до этого никогда ничего не удалял — просто менял статусы записей. Вот такая вот не успешная история в юзабилити phpmyadmin.
хочу немного уточнить по пункту :-)
3. Делайте. Делайте. Делайте. Начинайте разработку. Немедленно. Не зацикливайтесь на говорении, писанине, планировании и пр.
И поменьше читать такие книги. Такого рода информация лишь даёт уверенность в том, что ты идёшь правильно и не более. Информацию надо читать в момент её востребованности и актуальности. Говорящий не знает — знающий не говорит.
Возврат денег сильно зависит от типа оказываемых услуг. Понятно, что для услуг, описанных в статье речь, идёт о материальных приобретениях и тут как бы в любом случае столкнёшься с такой проблемой. Но в любом случае нужно идти на уступки клиенту – кто знает, что ждёт тебя в будущем с этим клиентом. В моём случае есть другая ситуация – мне клиенты платят за услуги и бывают случаю, когда клиент по ошибке оплачивает несколько раз. В данном случае не было случаях чтобы клиент запросил денег обратно. При данной ситуации я оповещаю клиента о его щедрости и предлагаю со своей стороны – дополнительные конфетки. Думаю что в случае с материальными услугами – необходимо запастись аналогичными конфетками. Клиенту необходимо дать возможность выбрать что то ещё. В этом случае у него даже мысли не появиться о возврате. Понятно что конфетка стоит дополнительных денег и что могут не покрыть расходы – но зато:
1. Деньги остануться у вас – никаких рефандов!.
2. И самое главное - клиент останется – ДОВОЛЕН!
Сейчас на работе пытаюсь использовать подход MVC при переводе живого проекта. Первая задача отделить бизнес объекты и логику.
Есть ряд проблем следующего плана. Допустим сейчас у меня есть такое разделение.
1. Модель это бизнес объект и имеет свои какие то проперти
2. Контролер это доступная логика по работе с бизнес – объектом (возрат списка объектов, добавление объекта и так далее )
Проблема возникает на этапе реализации котроллера для объектов, что имеют кучу хранимых процедур с параметрами. Например, хранимая процедура выбора с 5-6 параметрами, которые в свою очередь не всегда являются свойством объекта. Соответственно дописать в контролер их нельзя нарушает принцип MVC, c другой стороны мешает работать с уже наработанными хранимыми процедурами, что выполняют часть задач контролера. Есть один из выходов это дублирование логики хранимки на LINQ.
(+) тарифный план «Virtuozzo VPS Basic» 18 360 руб. (1 год)
Не сказал бы, что это навороченный впс. Более менее подходит для сайтов с посещаемостью 3 — 6 тыч в сутки.
тарифный план «Virtuozzo VPS Basic» 32 640 руб. (2 год)
18 тыч это дорого для VPS. — по сути издержек то особых для компании нет. Нарезали виешек и всё. Технической поддержки особо нету. Самому надо настраивать dns, почтовый сервер и прочее. Кроме апача и мускула по умолчанию ничего нет для старта работы.
В этом случае действительно выгодно купить железо — опять же настроить самому но потом платить только за аренду — финансово будет выгодно.
1. — Перезагрузка сервера зачастую без уведомления.
2. — Падение на 2-3 часа без понятных причин.
3. + Одноразовые вложения и далее только оплата аренды стойки.
При покупке VPS в год средняя цена более менее 30-50 тыч обходится. Интересно, какова его будет цена — будет ли входить в пределы 30 тыч? Если да — то однозначно лучше виртуализации до тех пор пока не произойдёт падение цен. Всё таки VPS сейчас довольно дороговат в России. И качество далеко не хорошее.
/*
Компания по перерегистрации ООО стартует в 2009 году, и должна быть завершена до 1 января 2010 года, что не представляется реальным для таких экономически активных регионов, как например Москва и Санкт-Петербург. По нашему мнению, перерегистрация ООО будет продлена до 1 июля 2010 года как минимум
*/
То есть проскальзывает мысль — а вдруг продлят. Ох как не хочется этим заниматься :-)
Допустим есть список категория следующего вида:
Id
parentId
Есть товар который имеет Id категории. Необходимо, по какой то выбранной категории выводить товары всех подкатегорий. Решение очевидно – рекурсия на стороне php или mysql. Это можно обойти если использовать дополнительную колонку в таблице категорий которая имеет в своём значении перечень всех подкатегорий по отдельной категории, то есть:
Id
parentId
childIds // 10,12,23,19
То есть необходимо однажды выполнить рекурсивный запрос для поиска всех Id подкатегория по конкретной категории и сохранить. Дальше просто. Изначальная проблема решается 2-мя запросами. Первым достаём значение childs, вторым получаем все товары
Select childsId from category where Id=10;
Select * from product where category id in (childsId);
3. Делайте. Делайте. Делайте. Начинайте разработку. Немедленно. Не зацикливайтесь на говорении, писанине, планировании и пр.
И поменьше читать такие книги. Такого рода информация лишь даёт уверенность в том, что ты идёшь правильно и не более. Информацию надо читать в момент её востребованности и актуальности. Говорящий не знает — знающий не говорит.
1. Деньги остануться у вас – никаких рефандов!.
2. И самое главное - клиент останется – ДОВОЛЕН!
Есть ряд проблем следующего плана. Допустим сейчас у меня есть такое разделение.
1. Модель это бизнес объект и имеет свои какие то проперти
2. Контролер это доступная логика по работе с бизнес – объектом (возрат списка объектов, добавление объекта и так далее )
Проблема возникает на этапе реализации котроллера для объектов, что имеют кучу хранимых процедур с параметрами. Например, хранимая процедура выбора с 5-6 параметрами, которые в свою очередь не всегда являются свойством объекта. Соответственно дописать в контролер их нельзя нарушает принцип MVC, c другой стороны мешает работать с уже наработанными хранимыми процедурами, что выполняют часть задач контролера. Есть один из выходов это дублирование логики хранимки на LINQ.