>>Однако если объём хранилища и степень его связности велики,
>>штанишки MySQL оказываются коротковаты. Ни эффективная работа
>
>Объем может превышать 1e5 записей, причем, видимо, они будут
>помещаться в нескольких таблицах, связанных ключами.
>Это совсем немного.
>>ни способность эффективно утилизировать возможности "big iron"
>
>А какие это возможности?
>
Главным образом, гигантская память с неоднородным временем доступа,
хитроумная высокопараллельная подсистема ввода-вывода, а также
большое количество процессоров. На уровне ОС многое делается
для обеспечения эффективной утилизации всего этого богатства,
однако и от СУБД очень многое зависит. Впрочем, если судить по
Вашему описанию задачи, в данном конкретном случае для Вас всё
это несущественно. Если бы предполагаемый объём операций над
хранилищем составлял, скажем, с четверть миллиона ежедневных
вставок либо обновлений ежедневно, тогда имело бы смысл огород
разводить.
>>данной СУБД. А data warehouse на MySQL строить, IMHO, безумие.
>
>warehous - это что-то типа стандартного комплекса
>взаимосвязанных баз данных для огромных
>финансовых корпораций?
>
Я не распологаю моральными силами и временем для сколько-нибудь
полного ответа. Можно посмотреть
http://en.wikipedia.org/wiki/Data_warehouse.
Существуют стандартные решения для организации корпоративного
хранилища информации. Сам термин существенно шире.
>Прошу прощения, что я в этом не разбираюсь, может быть это выглядит
>дико... Однако, я понял, что MySQL сильно проигрывает по
>способности лопатить большие и сложные базы при большой частоте
>транзакций.
>
Как обычно - смотря на какой базе и при каком (качественно и
количественно) потоке запросов. На MySQL живёт LiveJournal,
нагрузочка на БД у них - не дай боже такое самому увидеть.
Справляются за счёт грамотного распределения данных по множеству
баз на разных серверах.
>>И для них существуют такие монстры, как DB2 и Oracle; до недавнего
>
>А в чем монстризм? Больше места на диске, более изящный и правильный
>код, меньше ошибок, больше настроек?
>
Насчёт "больше места на диске" - размер дистрибутива малосущественен
(кроме разве что совсем маленьких БД), а размеры хранимых сырых данных
для хранилищ сравнимого размера обычно более-менее одинаков, даже
для разных СУБД. Разброс в 10-20% IMHO не существенен.
Насчёт "меньше ошибок" - может, и так. Баги есть у всех; здесь трудно
сравнивать.
Говоря про "монстризм" (кстати, смачное слово:), я имел в виду то,
что промышленные СУБД весьма хорошо масштабируются "вверх" (больший
объём хранимых данных, больше запросов, плюс более злое железо -
и работа снова пошла, программных затыков нет), но у них есть
явная планка, "ниже" которой они масштабироваться не могут (объём
усилий по настройке и мощность железа не могут быть ниже X и Y,
соответственно). Так вот эта нижняя планка реально задрана весьма
высоко. Можно и не допрыгнуть.
>>Стоимость лицензии
>>на ORACLE начинается с USD 1000.
>
>А у них в лицензии написано, кажется, что я могу бесплатно использовать
>Oracle для разработки. Стало быть, если я свои разработки не
>распространяю, а уж тем более не продаю, то вроде ничего не нарушается.
>Так ли это?
>
Не так. Для соблюдения условий лицензии Вам нужно свои разработки ещё
и не использовать. Ни для чего, кроме целей отладки. С формальной
точки зрения, использование ORACLE для любой цели, кроме целей
разработки использующего энтот самый ORACLE софта, требует приобретения
лицензии.
>
>А обслуживание Oracle более накладно?
>
Пожалуй, да. По крайней мере, специалиста-администратора найти труднее,
и денег он запросит явно больше.
>А если база впоследствии разрастется/усложнится до таких параметров,
>что понадобится Oracle, легко ли потом будет данные из формата одной
>базы перегнать в формат другой?
Смотря насколько сложна структура базы данных, используются ли
специфические мозможности (типа полей автоинкремента, которых
в ORACLE в явном виде не водится). СУБД сродни игле - если
крепко сел, соскочить тяжело.
