Подскажите плизз про движки

Не угадали. Это OS390/OS400. Там в качестве ФС используется полноценная DB2 :)

Заумь конкретная, но когда в идеологию въезжаешь - то просто прешься :)

А какие СУБД у микрософт? Недоросль MS SQL? ДыБы-МуДыБы всуе не упоминайте... она даже как таблица не очень :)

Удален повтор

32.000 файлов в папке максимум. это связано с образом папки который создаётся при чтении фала(смутно разобрался). причём чем больше файлов в папке тем дольше обращение. в последних ядрах линукса пока непофиксино. как решение - разбиение на подпапки

По теме поста

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

2. Исключи движки, которые складывают все картинки к статьям в одну дирректори.

3. Исключи движки, которые хранят контент не в базе а в виде HTML страничек.

А так выбирай любой . 100.000 записей в таблице для любой базы данных - енто фигня.. возможно мускуль будет виснуть при like запросах, да и то наврядли. а нужны ди тебе like запросы ??

Выбери нормальный хостинг, особое внимание удели тому сколько процессорного времени будет отводица на твой MySQL процесс.

Чё эт вдруг MSSQL вдруг стал недорослем? Промышленная база, работаем уже 8 лет и не жужжим. Производительность высокая, возможностей - масса. Единственный конкурент - Oracle, с ним тоже работаем. Все остальное можно конечно называть любыми уничижительными терминами, в частности MySQL. Но я бы поостерегся :) - все со временем сильно прогрессирует и растет. И если года 3-4 назад MySQL был стопудовым недоСУБДом, то сейчас для определенных приложений это вполне себе уже зрелое решение. Правда мы с ним не работали никогда плотно, поэтому я толком его возможностей даже не знаю. В основном недостатки только :).

Кстати: по теме-не по теме не знаю, но мы там в соседних тредах обсуждали где-то кэширование недавно. Надысь тут на нашем движке сайт сотового оператора собрали, ну и в первый день было 30000 хостов - реклама и всякое такое. Так блин кэш в первые полдня отключился из-за ошибки в настройке админами наших партнеров и при этом система все выдержала, загрузка проца была правда приличная. Но не 100% слава богу, думаю резервов там было еще дай боже, жаль с амперметром к клеммам не пустили :). А потом кэш подключили - и вся какая нагрузка была на проц - вся кончилась, упала в 50-60 раз. Это я возвращаясь к теме топика - хоть 90000 статей, хоть 90000000 - даже обычные статические кэши с генерацией кэша по мере необходимости и без всякой специализации на задаче в реальности крайне эффективны.

то сейчас он любой MSSQL обойдёт.

То что вы с ним не работали это вовсе не значит что они над собой не работали :)

(3-4 года назад это была недоCУБД я согласен, но с тех времён всё изменилось не просто сильно, а очень сильно...)

не обойдёт .. не собирается обходить и не будет .. при выборке из милионов 10 записей время выборки у мускуля будет на порядок выще чем у микрософта.. би-деревья и калиброванные тестовики - это совершенно разные технолгии ..

да и не о том речь .. каждый инструмент хорош для своих целей ..

и для сайтов и небольших информационных систем, лёгкгая, стабильная, пркатически не администрируемая MySQL DB - самое оптимальное решение на сегодняшний день !!!!!

как по простоте разработки так и по стоимости владения

Мы с MSSQL соскочили еще 9 лет назад. На версии 6.5. Никто не спорит, для определенных не очень больших задач она хороша. Один недостаток - платформа MS, которая в свою очередь упирается с Intel архитектуру. 1С с парой сотней пользователей - очнень хороший пример. У меня перед глазами пара контор, которые пытаются выжать из Intel архитектуры макимум ( кроссовер с терминальными серврами, раздельные сервера для совершения действий и просмотра, изощренная система их синхронизации и.т.д. ) То, что они потратили за 2 последних года на поддержание работоспособности в 2 раза превышает стоимость начального сервера RISC архитектуры и ораклом или DB2. А решения по портированию нет :(

Да и 1С 7 и 8 версии абсолютно несовместимы.

Согласен. Правда, как и во всем, тут важно не переборщить. :)

У нас много интранет решений, где своя специфика... статические кэши - не всегда панацея.

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

Приведу аналогию с перевозками:

Есть задача - развозить небольшой груз до 200 кг по городу - в этом случае Вам придется покупать Каблучок - дешево и сердито.

Объем груза увеличился - можно использовать 3 каблучка или 1 газель.( это уже другой класс).

Увеличилось расстояние - можно отправлять груз газелью, а можно и магистральным грузовиком, взяв до кучи еще груз.

если речь и дет о сотнях тонн, обычно используют железнодорожный транспорт, или в результате, смешанные перевозки. Т.е. Железная дорога - Магистральный тягач - Каблучок или газель. :)

Я никоем образом не агитирую делать сайты на 100 страничек на Oracle, хотя, думаю, что при наличии мощностей, их инструментария и лицензий - это будет недорого.

Я просто обращаю внимание, что формулировка "90 000 документов" очень расплывчата. Надо понять, что надо делать с этими документами, какая должна быть модель представления данных и модель безопасности. Какой объем в документах будет через год, а через 3 года? Какой планируется трафик?

Только ответив на эти и еще множество вопросов можно говорить о том, что может встать в основу этой информационной системы.

А скорость по вашему это единственный критерий оценки СУБД ?

транзакции, встроенные процедуры, хранение объектов, полнотекстовый поиск, курсор выполнения..

могу перечислить ещё .. нуна ?