Делаю скрипты на заказ без MySQL, любой сложности

Я считаю, что СУБД - удобное средство работы с данными. Т.е. ничего проще работы с СУБД в плане "обычных" четырех операций добавления, удаления, апдейта и выборк нет.. Не говоря уже о поиске =)

ЗЫ: а страничку лучше-таки собирать в кеш (блочное, модульное, полное кеширование).

T.R.O.N, преимущества СУБД,имхо, не в хранении, а в мунипулировании информацией, и даже не столько информацией, информацией в более-менее приличных объёмах.

Ну и когда есть наработки по коду, то проще для написания простенького сайтика использовать их, чем писать ещё прослойку для работы с файлами, часто специализированную.

Это если смотреть со стороны сторонника MySQL и прочих бд.

Вот-вот. Делаем паровоз для машиниста. то что все тормозит - это фигня. Юзер подождет. Если Вы действительно так и подходите к вопросу, как написали - то все что чуть сложнее домашней странички будет кошмарить посетителей.

Но вренусь к началу. Если действительно у Вас некая часть сайта предназначина для вывода/редактирования данных, при этом отношения оперций с базой имеет значение чтение/запись(обновление) =~ 100/1 - 1000/1 - безусловно все оправдано. Если нет - ищите другие решения, если только Вам не наплевать на посетителей.

T.R.O.N добавил 13.04.2009 в 15:55

безусловно. Я тольок говорю о том, что решний значительно больше одного.

Если сайт расчитуется на 1-500 уников с сутки - любое решение потянет. Начиная от массовых цмс до статики.

T.R.O.N, не стоит уж так напрягаться может?

Разработка собственной (более-менее приличной) системы управления и хранением данных - это не месяц работы даже. Ну не думаю я, что удастся вот так с полпинка тот же поиск огранизовать.

Возьмем сопровождение кода. Изменить логику приложения с СУБД - это полпинка, а что делать, если ваш код будут сопровождать сторонние программисты? Изменение обычного запроса - пляски с бубном. Нужно хорошо знать как работает конкретная система. А что насчет расширения?

Плюсом присутствия СУБД в приложении является существование стандартизованных интерфейсов доступа к данным (взять тот же PDO). Смена СУБД - вопрос переноса данных и не более. Не понадобится даже менять приложение (в большинстве случаев). Может быть, кое-где только поправить запросы в соответствии со спецификой конкретной СУБД (яркий пример - count(*) или count(1) - вы ведь понимаете о чем я?).

В большинстве случаев это даже не даст прироста производительности. А разработка хорошей системы работы с данными по стоимости не будет дешевле практически любой коммерческой СУБД.

ИМХО, конечно... =)

UPD: еще раз напоминаю о кешировании. Вы его преднамерено "забыли" упомянуть в предыдущем посте? )

UPD2: может, отдельный топик для холливара откроем? А то бедный ТС скоро потеряет возможность получить потенциальных заказчиков =)

Ну почему, не стоит забывать и об "облаках" - используя уже готовые решения можно сэкономить на разработке полноценного решения.

Dreammaker добавил 13.04.2009 в 16:13

Скорее пусть модераторы выделят флуд в отдельный топик.

Гыгыг. А облака так увеличат производительность относительно производительности СУБД, о которой так заботится уважаемый T.R.O.N?

UPD: А никто и не спорит о преимуществах готовых решений для типичных задач. Может даже и для нестандартных задач =)

asserte, Вы говорите все правильно, если предположить что решается задача где хранение данных в базу (мускул, ацес и т.д.) имеет смысл. Я же говорю о тех задачах, где это не имеет смысла вовсе. И не имеет значение какой вараинт субд используется. В частности, использовать мускульные базы в цмсках, где обновление данных происходит на 0,1% в месяц (при этом все страницы собираются 'налету' из базы для каждого просмотра) - просто абсурд.

Понимаю, - последовательность мыслей понятна, - книжку в пхп в зубы, там есть основы мускула. Серва, вобщем, мощьный. Ура. Получилась цмс.

T.R.O.N добавил 13.04.2009 в 16:16

не всегда - но увеличивают, оптимизируя то, о чем большинство программеров не задумываются

asserte, если читать то что пишет уважаемый T.R.O.N, то можно понять, что он говорит, что каждая задача тербует своего подходящего решения.

А в случае, когда требуется горизонтальное масштабирование, то cloud-технологии могут быть выходом.

Дык о нужном для каждого решения инструменте говорим мы все. Поэтому предлагаю закончить холливар. Всем спасибо +)

считаю такие вещи признаком неопытности

имхо