Вот это Вы уже зря. Так и битрикс родился... Что хорошего от этого?
Нагрузка софта должна компенсироваться архитектурой. Как частный случай - распределением на разные железки ;)
Дык о нужном для каждого решения инструменте говорим мы все. Поэтому предлагаю закончить холливар. Всем спасибо +)
Гыгыг. А облака так увеличат производительность относительно производительности СУБД, о которой так заботится уважаемый T.R.O.N?
UPD: А никто и не спорит о преимуществах готовых решений для типичных задач. Может даже и для нестандартных задач =)
T.R.O.N, не стоит уж так напрягаться может?
Разработка собственной (более-менее приличной) системы управления и хранением данных - это не месяц работы даже. Ну не думаю я, что удастся вот так с полпинка тот же поиск огранизовать.
Возьмем сопровождение кода. Изменить логику приложения с СУБД - это полпинка, а что делать, если ваш код будут сопровождать сторонние программисты? Изменение обычного запроса - пляски с бубном. Нужно хорошо знать как работает конкретная система. А что насчет расширения?
Плюсом присутствия СУБД в приложении является существование стандартизованных интерфейсов доступа к данным (взять тот же PDO). Смена СУБД - вопрос переноса данных и не более. Не понадобится даже менять приложение (в большинстве случаев). Может быть, кое-где только поправить запросы в соответствии со спецификой конкретной СУБД (яркий пример - count(*) или count(1) - вы ведь понимаете о чем я?).
В большинстве случаев это даже не даст прироста производительности. А разработка хорошей системы работы с данными по стоимости не будет дешевле практически любой коммерческой СУБД.
ИМХО, конечно... =)
UPD: еще раз напоминаю о кешировании. Вы его преднамерено "забыли" упомянуть в предыдущем посте? )
UPD2: может, отдельный топик для холливара откроем? А то бедный ТС скоро потеряет возможность получить потенциальных заказчиков =)
Я считаю, что СУБД - удобное средство работы с данными. Т.е. ничего проще работы с СУБД в плане "обычных" четырех операций добавления, удаления, апдейта и выборк нет.. Не говоря уже о поиске =)
ЗЫ: а страничку лучше-таки собирать в кеш (блочное, модульное, полное кеширование).
Так же интересует тз, сроки, авторские права.
Далеко себе не единственный способ. Но для большинства задач дешевле использовать существующие СУБД, не?
Посмотрите на код ТС и ответьте: этот человек способен написать ПС / крупный портал с приемлимой стоимостью поддержки? Это таки ключевой момент ;)
1. Смесь логики с отображением
2. Неиспользование стандартных средств проверки на пустоту
3. Код Non-strict стандарта.
ТС, а зачем топик удалять? Чтобы скрыть свои косяки? Считаю удаление недопустимым (не в коем не указание модераторам.) ибо это - ваша репутация. От данного аукциона она заслуженно упала. Ничего личного.
A-des, на мой вкус - вообще не связываться с ТС бы.
Даже гавно продавать можно. Только поддерживать его после ТС будет нереально.
