Tar_As<...>Имеется ввиду не 200 тыс. записей, а 200 тыс. пользователей!<...>
Если и когда станете владельцем MMORPG с 200k подсевших - Вас меньше всего будет беспокоить СУБД. А для начала я бы сделал прототип на 3 игроков и 30 NPC, на какой-нибудь FOSS IMDB .

IMHO вряд ли MMORPG с 200k пользователей "отобьёт" стоимость ПО от Oracle, необходимого для её построения, и специалистов, необходимых для её поддержки.

Tar_As<...>
Из опыта знаю, что, например, программы от Borland (Delphi) хорошо рекламируются как заточеные под работу с БД, а на деле сравнил с FoxPro - небо и земля! То что на Delphi пишется длиной в строку, на Foxe выражается одним словом, ну и т.д.
Есть опыт работы с локальной БД в Delphi (Paradox) и написания запросов.
Вряд "отобьёт" они также стоимость любых проприетарных ОС и ПО, особенно от весьма жадной MS. Да и вообще, то, на чём Вы собрались писать, очень плохо подходит для создания высоконагруженных систем с весьма нетривиальной, изменяющейся бизнес-логикой.

Я бы писал "ядро" и "графику" клиента на C++ (для прототипа - хотя бы на C#.Net), "ядро" сервера на C++ (для прототипа - хотя бы RTSJ) под промышленным Linux, клиентскую и серверную бизнес-логику - на Lua.

Tar_As<...>Выбор БД уперся между MySQL и PostgreSQL<...>
Ни одна из них для MMORPG не пригодна.

Tar_As<...>OracleExpress на хостинг мне ведь не дадут?<...>
Это будет не MMORPG. У MMORPG не бывает хостингов, по крайней мере, дешёвых, на которых пользователь не контролирует весь хост. Купите у провайдера "белый" IP (это недорого), пробросьте на какой-нибудь старенький, регулярно бэкапящийся комп с linux, и используйте. Потому что MMORPG - это системы реального времени. На MMORPG, не являющуюся системой реального времени, говорят "лагает", при "лагах" в такую MMORPG перестают играть.

Tar_AsMySQL - много литературы, но есть сомнения в производительности.<...>
См. динамику её производительности от размера БД и кол-ва пользователей. Но важнее функциональность, поддержка, надёжность, масштабируемость - именно в таком порядке.

Tar_AsPostgreSQL для освоения серверной СУБД думаю выбирать не стоит.<...>
Это Вы зря - хорошая, академически самая "правильная" СУБД с открытыми исходниками.

Tar_AsЕсть мысль, что производительность должна в основном зависеть от правильности кода и мощности/пропускной способности сервера, а нет от типа СУБД. Вряд ли принципы обработки данных сильно разнятся в разных БД.<...>
Производительность зависит и от того, и от другого.

Tar_AsСледующий вопрос касается выбора активного ПО на сервере и на клиенте. Еще подробно не изучал, но похоже придется выбирать между Java скриптами и PHP. Что скажете?<...>

Если Вам хочется изучить программирование - не обманывайте себя, изучайте программирование. Впрочем, JS и PHP - не то, с чего я бы порекомендовал изучать. Начинайте с Pascal, продолжайте C++.

Впрочем, 10 лет назад были "текстовые" MMORPG, а-ля:
>"g u"
"вы идёте на север, и видите дракона, сидящего у стены"
>"h s"
"дракон уклоняется от удара копьём"
"дракон невыносимо больно бьёт вас огнём"
"вы умерли" .

Можете попробовать сделать такое - поймёте принципы взаимодействия игровых объектов.

Tar_As
Как производительность разн и ца между вариантом скомпилированых CGI программ по сравнению с ASP (при большом кол-ве обращений)?
При прочих равных - "драматическая", а вообще зависит от своевременной оптимизации.

Tar_As
По идее скомпилированый код должен выполнятся быстрее интерпретации. Но с другой стороны выделит ли ОС коду CGI время? Интерпретацию, насколько я понял, выполняет сам Web сервер и приоритет у него может оказаться выше?
У MMORPG есть "сервер игры", и есть вспомогательный, административный "веб-сервер", с форумом, регистрацией, иногда - картой и управлением персонажами. Конечно, можно использовать Apache и в качестве платформы для "сервера игры", но это лишний слой ПО, плохо совмещающийся с требуемым "мягким" реальным временем.

Есть сервер бизнес-логики или веб-сервер.

К нему обращаются пользователи игры. Вам важно оценить, как часто пользователи игры обращаются к этому серверу с клиента. Допустим, X раз в секунду.

Есть сервер БД; на одно обращение клиента к серверу бизнес-логики или веб-серверу может быть Y обращений к серверу БД.
Определите также средний состав запросов:
- соотношение запросов выборки и запросов модификации
- средний объём данных, над которыми производятся операции чтения и операции модификации
- сложность условий
- типы данных, размеры таблиц
- среднее кол-во операций в транзакции и т.д.
Вообще идеально, если к этому моменту будет проект системы, в т.ч. схема БД.

Количество запросов в секунду, который должен будет обрабатывать сервер БД, Z=X*Y . От него, и от состава запросов, отталкивайтесь при выборе СУБД.

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

Tar_AsЧто быстрее работает?
Конечно скомпиллированных код. При условии, и что интерпретируемый, и скомпиллированный код написан одинаково компетентными людьми.

AAronдаже если это MMORPG - СУБД это не ваш вариант, точнее РСУБД. Вам нужно что-то из ООСУБД. Поищите, неоднократно на форуме обсуждались. Задача одновременной поддержки сотен тысяч пользователей проще реализуется на встраиваемом движке с нативными маппингами между системой хранения и кодом приложения.
На форумах это обычно вызывает "религиозные" войны между теми, кто смирился с SQL и реляционной моделью, и "умеет их готовить", и теми, кто не смирился, не умеет, уметь не хочет и ищет что-то взамен (не всегда это плохо). Давайте не будем начинать ещё одну и скажем так: производительность и масштабируемость зависят от головы и рук, и не зависит от парадигмы.