Как раз в тему по данному топику сегодня одному ораклисту удачно высказался один из разработчиков команды ASA на их официальном форуме:
авторIf you *want* big, fast and expensive, go with Oracle or DB2. If you
want small, fast, friendly and affordable, go with ASA 9. It's your
call, some folks *like* to spend money :)
Полностью с этим высказыванием согласен - нечего ту же ASA пытаться запихнуть на задачу с огромными обьемами данных и большим кол-вом подключений. Так же нечего делать на Оракле задачи, которые должны работать в удаленных филиалах автономно (без какого либо администрирования) с какой то сотней гигабайт и 70-100 активных сессий. Легче в центре поставить Оракл, по удаленным филиалам ту же ASA, и через ее механизм репликаций спокойно обмениваться информацией, хоть в онлайне, хоть в оффлайне. Благо на текущий момент ASA 9.0.1 по реализации ANSI SQL и расширениям ничем не уступает тому же Ораклу или DB2, разная только архитектура СУБД, что и правильно с точки зрения круга применяемых задач (насколько я знаю, последнее оставшееся известное мне отличие ASA WatcomSQL от PLSQL - это (Field1, Field2) IN (SELECT Field1, Field2 ...) - будет реализовано этим летом в 9.0.2).

То же касается и MSSQL - эта СУБД имеет свою архитектуру и свой круг задач, хотя хочу заметить, что в данном случае команда iAnywhere поступила мудрее, не соперничая с другими СУБД, а заняв свою нишу задач мелкого и среднего бизнеса и сделав возможность полноценной работы с другими СУБД через прокси-таблицы и гетерогенную репликацию. Судя по форумам ASA такая политика там приносит свои плоды - выгоднее разбить проект на 3 части - центральный (Оракл), удаленный (ASA9) и мобильный (ASA9 UltraLite), съэкономить денюшку (сервер ASA9 - 400$, лицензия 100$, на процессор 2500$) и не чесать репу - а как это запустить проект на Оракле в филиале Магадана, где не то что сисадминов, но и интернета то нету, или как всем мобильным сотрудникам поставить СУБД на КПК PocketPC/Palm с репликацией на центральный сервер :) IMHO все что касается любых удаленных или автономно работающих промышленных СУБД здесь у ASA конкурентов нет.

И кстати ограниченность MSSQL по сравнению с другими СУБД имеет свои явные плюсы - в конце концов люди хоть учаться правильно проектировать БД и писать запросы. IMHO вседозволенность хороша только специалистам с большим стажем, которые четко знают, что можно, а где лучше остановиться. Иначе получается такое ... что волосы дыбом встают. Я вот до сих пор на форуме Sybase борюсь с "курсорниками", которые пытаются в обязку сделать UDF, в нее запихнуть курсор и вызывать эту UDF из запросов. Считаю это явным антирелляционным подходом и полным пренебрежением наличия отличного самообучающегося оптимизатора. Кстати забавно, но большинство "курсорников" почему то оракляне. Я вот все никак не могу понять - то ли мне не везло на разработчиков Оракла, то ли на Оракле с помощью курсоров, в отличие от MSSQL, ASE, ASA можно действительно быстро и эффективно перелопачивать данные, хотя все равно возникает вопрос - а разве по любому план запроса, сделанный оптимизатором не будет эффективнее ?

авторВстроенный оптимизатор (план выполнения), желает желать лучшего
...
Если запрос сложен, приходится последовательно строить несколько вьюверов.
Ой, что то я сомневаюсь, что у MSSQL так плох оптимизатор запроса, раз Вы любите вьюверы строить на сложные запросы. Вот думаю народ, работающий на любой СУБД не даст мне соврать: увлекательство представлениями - это прямой путь к тормозам. Плюс на личном опыте могу сказать, что как минимум у MSSQL и Sybase ASA при соединении в плане запросов основного запроса и вьювера в некоторых ситуациях (чаще LEFT JOIN) может привести к тому, что оптимизатор проведет не то соединение, которое ожидалось и результат выполнения просто вьювера и использование его в запросе будет отличаться.

Так что лучше при написании сложных запросов не забывать о временных таблицах, которые позволяют разбить на несколько этапов сложный план запроса и упрощают жизнь с блокировками. Жалко только, что в MSSQL до сих пор нет NOT TRANSACTIONAL времянок, на примере ASA могу сказать, что они дают неплохой выигрыш в скорости. Так же бы не помешали GLOBAL TEMPORARY TABLE, описание которых хранится в БД и они автоматом создаются для каждой стартующей сессии в своем контексте данных (на них даже триггеры вешать можно).

IMHO с точки зрения проектировщика: MSSQL хороший сервер, но по возможностям ему явно не хватает функциональности для реализации всей логики на сервере. Например в ASA я имею глобальные сессионные переменные, возможность реагировать и выполнять свой код на различные события, в т.ч. на подключение и отключение сессии. Как результат - БД на ASA у меня действительно полностью автономна - не нужно с клиента чего то создавать или запускать ХП, при подключении сессии все что нужно инициализируется сразу. Такие возможности позволяет в дополнение контролировать подключение и например отказывать в доступе по IP или имени приложения. Или же при реализации собственных блокировок автоматически удалять их с таблиц при отсоединении сессии.

andbaryА пока... у меня 7 сущностей (должна быть 1) и каждая состоит из 10 связанных таблиц... и я объеденяю все в одном запросе...
В Оракле можно вручную указать порядок выполнения... а оптимизатор MS на такое (количество связей) просто не расчитан...
Если рассуждать чисто филосовски, то одна медаль имеет 2 стороны. На одной стороне достоинство Оракла в полном доступном тюнинге СУБД, позволяющего работать даже с кривыми решениями и как следствие недостаток других СУБД, не имеющих таких возможностей. На другой стороне медали с точностью наоборот - явные, открытые для пользователей настройки СУБД не стимулируют разработчиков Оракла к усовершенствованиям в области движка СУБД и и его пользователей к написанию более кач-венных решений. А зачем ? - если оно и так работать будет. В том же MSSQL ситуация получается благополучной - его "ограничения" с одной стороны развязывают руки MS, которая может более спокойно совершенствовать свой движок СУБД, так как он не завязан на "тонкие настройки" сисадминов, а значит не имеет жесткой зависимости от них.

Из всего вышесказанного я делаю вывод: Ваш пример не годиться, так как могу со всей уверенностью заявить, что на MSSQL никто бы просто не додумался так спроектировать БД (она бы просто не работала), а значит у Вас не встал бы вопрос насчет такого кол-ва таблиц в запросе, будь это решение не на Оракле.

P.S. Кстати на недавно проходившей конференции по OLAP серваку Sybase IQ, приезжавший специалист по нему как раз рассказывал и демонстировал решения, переведенные с других СУБД и обьяснял причины. С переводами с MSSQL было все понятно - блокировочник, да и все таки движок не рассчитан на обработку террабайтов информации, а вот с Ораклом было интереснее. Именно на нем частой мотивацией перевода аналитической БД на платформу IQ было кривизна решения. Например, нам продемонстировали схемку, где у одной таблички было пятьсот с чем то полей. Естественно когда БД стала большая, то тут и Оракл стал заваливаться на бок, хотя народ пытался все это дело разрулить разными дикими способами, вплоть до разделения таблицы на целую группу таблиц (на Sybase IQ потом перенесли первоначальную схему, ему в принципе все равно, сколько полей в таблице). Я лично из всего увиденного на конференции и сказано сделал для себя в общем то известной для всех в бытовой жизни вывод - "2 в одном" всегда хуже, чем по раздельности. Лучше уж иметь в проекте чистые OLTP-блокировочники, не требующие администрирования и имеющие более менее граммотные оптимизаторы, плюс для консолидированной БД чистый аналитический или OLAP сервер, вполне возможно версионник, для того, чтобы не иметь проблем с закачкой данных (как тот же Sybase IQ), но специально оптимизированный под хранение и обработку больших массивов информации. Оракл же получается вроде как два в одном: OLTP + OLAP. Соотвествующе это требует больших накладных расходов на него и сужения круга применения. Это конечно мое личное мнение, но согласитесь самолеты-амфибии и по воздуху хуже летают и по воде не так быстро плавают. Наверное что то в этом есть :)

авторрешение сайбеза я совсем не понимаю - зачем мне использовать в работе 2 совершенно не похожие технологии, требующие раздельного администрирования, серверов и т.п.
Ну если брать Sybase ASA и Sybase IQ, то вообще то эти решения не требуют администрирования (утверждаю со всей серьезностью). А насчет в разы - от ASA и не требуется мощь Оракла - ее задача стоять по филиалам и собирать данные, обеспечивать достаточную скорость и функциональность чистого OLTP сервера (с чем она успешно и справляется). Ну а сравнивать Sybase IQ (или подобные ему) с Ораклом надо на готовых решениях и конкретных базах, а не сайтах с синтетическими тестами.

автора то что вы сделали вывод на презентации блокировочника ... ну так не удивительно, уверен что ораклойд на той же презентации бы сделал совсем противоположный вывод.
Другой вывод на той презентации на демонстирующемся примере я сделать просто не мог - любой СУБД завалится на таблице шириной 500 полей и большим обьемом, кроме специализированного, который именно под аналитику и заточен. Sybase IQ не хранит данные по страницам, он их хранит по полям, а базы хранит в сжатом виде, поэтому аггрегатные запросы в нем по умолчанию будут быстрее выполняться, так как операции чтения с диска будут эффективнее, даже если бы оптимизатор запросов у него был плох (а он кстати неплох и является родственником ASA-оптимизатора).

Теперь насчет - зачем все это надо :) С одной стороны Оракл это крупное, комплексное ПО, со своей историей развития, достоинствами и недостатками. Лично я никогда не работал на Оракле, но много общался с людьми, которые на нем работают. И с программистами и администраторами. Видел решения - кривые и красивые. Но сложилось мнение, что в ситуациях мелких и средних решений, тиражных продуктов, для работы в кач-ве удаленных СУБД без каких либо намеков на администрирование или даже каналы связи - Оракл хромает, причем серьезно. В итоге те, кто для таких задач используют Оракл начинают садомазохизничать - пытаться подсадить всех на удаленный интерфейс по каналу 64к, написать самопальные оффлайн репликации, набирать админов для разьездов и т.д. Может быть я не прав, может быть я просто не видел достойных людей и решений. Ну а если здесь я прав, тогда возникает вопрос - а почему решения пишутся на Оракле в таких случаях, даже не смотря на такие ограничения и его цену, когда можно и ASA за 400 баков сервер купить, плюс сто баков на каждое подключение. Ответ лежит на поверхности - с 400 баков нормальный откат не получишь, технику для этой СУБД не проапгрейтишь. Ну а так как Оракл покупается как "единое комплексное решение", то даже закупку на удаленные филиалы других, дешевых и самоадминистрирующихся СУБД будет сложно - мы же уже купили штуку, на которой будет делать все, зачем нам еще что то ? Приходиться начальству и программистам чесать репы, как там его запустить. Из личной практики: обычно это заканчивается тем, что на удаленке продолжают крутиться Clipper и Fox, возможно с переделанными под Windows мордами, данные с которых уже пересылаются в центр, сливаются в БД на Оракле и все верхнее руководство просто уверенно - да, Оракл действительно комплексное решение.

P.S. Наверное мои речи не стоит воспринимать как наезды на Оракл или похвалу решениям Sybase, я можно сказать малость пофилосовствовал и попытался рассмотреть различные решения с разных сторон. Если коллеги, работающие на Оракле меня переубедят, что я не прав, покажут мне как Оракл не требует сильно навороченных апаратных решений, легко ставиться, работает удаленно без наличия администраторов, имеет репликации, которым могут даже через off-line работать, то я обязуюсь таких людей попробовать познакомить с моим начальством, которому навязали делать удаленные решения на Оракле и которые пока не нашли людей, готовых подписаться на такое. И правильно, что не подписались - начальство ставит одно условие, если ошибетесь, то админить вам Оракл в Магадане :)

Ну если 45-террабайтная база на Sybase IQ, 5000 активных коннектов и один скучающий администратор, которому начхать, какие запросы с какой селективностью выполняются на СУБД - это маленькая система, то я умолкаю :) Ваши утверждения насчет того, что в Оракле все давно было за 10 лет до появления Sybase IQ по меньшей мере странны - я ни разу не слышал, чтобы Оракл хотя бы поддерживал работу с сжатыми (до 50%) БД, а Ваши решения насчет вью было бы интересно посмотреть в работе на 40 террабайтах. Вы наверное его с Sybase ASE спутали - у Sybase 3 СУБД :) (ASA - SMB и мобильная СУБД, ASE - Enterprise и realtime СУБД, Sybase IQ - аналитическая СУБД).

Насчет сжатия таблиц Оракла - интересно, не знал, спасибо за ссылку.

Насчет тестов по DSS - так там и видно, что Sybase IQ идет в десятке лидеров вообще то, как по максимальному кол-ву записей, так и по размерам БД. (не забывайте прибавлять к размерам приведенных БД на IQ в тестах еще 40-50% от указанного, в IQ сжимается вся БД, а не отдельные таблицы, т.е. БД на 20 террабайт будет весить порядка 10 террабайт плюс-минус террабайт).

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

авторединственно где не оправдано использование оракла - маленькие системы в 10ки юзверов, это действительно может оказатся не эфективно.
Добавляем сюда еще фразу - "Или с множеством удаленных филиалов с десятками юзеров, без выделенных каналов связи и консолидированной базой в центре" и наконец таки получаем то самое, о чем я и говорил :) Тут связка MSDE + MSSQL, или Sybase ASA + Sybase ASA/ASE/IQ получается выгодней Оракла по сопровождению и цене. Ну а если у Вас есть возможность все филиалы на выделенку подсадить через тот же веб-интерфейс и Оракл один на всех поставить, то никто и не спорит, в таком варианте Оракл получается выгоднее по цене и сопровождению, я про это и не спорил :)

P.S. В итоге оправдывая названия топика еще раз скажу - главное хвост, т.е. обоснование использования той или иной платформы.

Yo!
Возникает парочка закономерных вопросов к Ораклу:
1. Если Оракл настолько крут и умен, что может самостоятельно жить без помощи людей, то зачем постоянно требуются администраторы на решения Оракл и за что им так много платят ? Увольнять их всех надо, как тунеядцев или зп срезать ?
2. Если Оракл рекордсмен во всем, то почему другие СУБД не только живут, но еще и неплохо живут ? (Россию в счет не берем, слишком здесь увлекаются патриотизмом в области ПО)

И лично парочка вопросов к Вам:
1. Работали ли Вы на Sybase и MSSQL, чтобы утверждать, что они из себя кроме тормозов и багов ничего не представляют ? (особенно интересует фактическое знакомство с Sybase ASA, раз уж Вы отрицаете то, что она не требует администрирования)
2. Верите ли Вы, что машина Бэтмана, умеющая ездить, плавать над и под водой, а так же летать, однозначно функциональнее и выгоднее, чем узкозаточенная кач-нная техника (Porshe, Боинг, и т.д.) и что для Вас выгоднее и дешевле - купить всем в своей семье Бэтменмобиль из за того, что у всех один движок, одни патчи и т.д., при условии, что Вы всегда будете летать, Ваша жена ездить, ребенок плавать по морю, а теща проводить разведку под водой ?

P.S. Ну а насчет "статей" - у меня на FAQ по Sybase ASA лежит ссылка на официальный документ, где подтверждатся тестирование Sybase ASA9 на IBM Benchmark на БД, размером 40гб и 3800 конкуретных подключений, с результатом на 400% скорости выше, чем минимально требуется для удовлетворительного функционирования СУБД. Но ведь эта статья ничего не меняет, не правда ли ? Мало ли что напишут, лучше ориентироваться на примеры работающих систем и личный опыт.

авторПлатят за то, что не существует идеальных операционных систем, железа и за то, что в оракле тоже есть баги. И платят много за поддержание жизненно важных данных, потеря которых приведет к закрытию фирмы. А на больших объемах данных можно легко пропустить какое-либо повреждение данных, исправление которого может быть нетривиальным явлением. Наконец, платят за принятие ответственности за те или иные решения.
Ok, у меня тиражный продукт, у которого не сильно большая БД (100 гигов на 100 подключений максимум). Нужны низкие требования к аппаратной части (обычные простенькие PC от P2-300 32 RAM) , поддержка оффлайн репликаций и отсутствие какого либо администрирования, где СУБД сама может принимать эффективные решения по нагрузкам и оптимизации на основании учета технических характеристик аппаратной части, запросов и самих данных БД (на основании статистики, обучения оптимизатора запросов, выявления и сохранения наиболее эффективных планов запросов и т.д.). Плюс требуется функциональная поддержка клиентского приложения, которое без администратора на уровне СУБД могло бы управлять Engine, подключать и отключать БД, проводить онлайн резервное копирование, онлайн дефрагментацию таблиц и индексов, отслеживать функционирование репликации и т.д. В общем все, что относиться к тиражным и удаленным решениям - может ли все это обеспечить Оракл, который облегченный (Standart Edition) ? Просто у меня под боком сидят разработчики на Оракле, которые однозначно говорят "Все из вышеперечисленного одновременно не сможет, так как есть множество ньюансов". Или они ошибаются ?

авторда я как бы такого не утверждал, я сылался на оракловые рекорды TPC-C, TPC-H, SAP ...
Там все какая то гигантомания наблюдается, у кого больше и кто быстрее. Sybase ASA не участвует в этих тестах по простой причине, что она SMB (средне-мелкие решения) и у нее нет задач вертеть консолидированными террабайтными базами. У нее задача обычного труженика: собирать, обрабатывать и пересылать этим базам входящую информацию с обычных PC и КПК.

Вдогонку:
авторэээ ... я отвечу но предлагаю в эту сторону не углублятся. у нас есть независимые тесты, документы и уважаемые аналитические канторы типа IDC и т.п. давайте просто подвеждать сказаное линками и все ... а то IBM где-то что-то намеряло и ... а в чем проблема с TPC-C ? синтетический ? тогда SAP ? а ссылочку на IBM было бы все таки интересно.
Беда в том, что лично я не признаю тестов и линков. Мне больше нравится смотреть на работающие решения или исходить из собственного опыта.

Ссылка на тест IBM BenchMark (посмотрел, сорри - там 3800 коннектов на 18 гб тестировjлась, а не 40 гб).
Ссылка на решения, реализованные на базе ASA (поставленная клиентом задача, мотивация выбора ASA, успешность решения, отзывы клиентов).

авторчто то я не понял, ведь только что вы говорили что он велеколепно тянет энтерпрайз и IBM что-то там намеряло, и вообще сайбез очень даже участвует и в SAP и в TPC.
Не поняли :) Мы обсуждаем SMB-решения (во всяком случае я так точно) для построения удаленных и тиражных продуктов среднего обьема. Sybase ASA (производитель - iAnywhere Solution, бывший Watcom) не участвует в TPC-тестах, так как не претендует на Enterprise звание в иерархии СУБД Sybase. В тестах участвует их родной продукт Sybase Adaptive Enterprise (ASE), который по фунциональности менее наворочен, чем Sybase ASA, однако может успешно молотить очень большие обьемы данных (на его основе сейчас выпущено СУБД для работы в реальном времени). Его я не обсуждаю, так как лично на нем не работал и насколько я знаю ASE очень близок по архитектуре с MSSQL и очень далек от Sybase ASA :)

авторконечно может, standart это тот же ЕЕ просто вырезаны совсем ентерпрайз фишки типа RAC, AQ кажется с материализет вью что-то покоцано. но не важно - коре тот-же, т.е. по каждому перечисленому пункту оракл более наворочен чем сайбез включая "на основании статистики, обучения оптимизатора запросов, выявления и сохранения наиболее эффективных планов запросов "
Тогда у меня закономерный вопрос возникает - если оптимизатор Оракла так наворочен, то зачем Violina топик в форуме DB2 организовала, спрашивая "А правда ли, что у них оптимизатор без хинтов сам может запросы разруливать ?" (кстати этот топик можно так же с успехом отнести и к ASA, там тоже все работает без хинтов).

авторP.S. еще раз - я не пытаюсь опустить сайбез в его стихиии SMB, там оракл не конкурент (на серверах за $100) я пытаюсь сказать что в техническом плане оракл был бы круче, но согласен что не пропорционально дорого. поэтому mysql, foxpro и т.п. инсталяций гораздо больше ....
Вот именно это я и говорю. Только никак не могу понять, почему Вы уверены, что в техническом плане Оракл был бы круче в SMB ? Что он умеет для баз данных мелкого и среднего обьема такого, что не умеет Sybase ASA, чем его решения помогут мне быстрее и эффективнее разработать и запустить проекты, и чем они будут выгоднее для моих клиентов, чем в том же ASA ?

авторВедь когда обычно проблемы вылезают, когда всплывают промахи в проектировании системы. На практике ведь как обычно бывает в больших проектах (системах). Проектируют одни люди, а кодят другие. Когда по мере развития системы возникает объективная проблема (все учесть заранее невозможно), то кодер пишет многоэтажные запросы, извращаясь как может. Вместо того, чтобы вернуть этот вопрос на уровень проектировщиков.
Согласен на все 100%. Кривое проектирование БД наносит серьезный удар по производительности и сопровождению проекта. И тут насколько я понимаю Оракл действительно сам вытягивает и дает администратору свободу по разруливанию таких кривых решений, когда тот же MSSQL просто заваливается и кроме как наращивания аппаратных средств других решений нет. В этом плане я даже спорить не буду, так как своими глазами видел супер-кривые решения на Оракле, которые все равно работали и супер-кривые решения на MSSQL, которые не работали несмотря на все предпринимаемые средства. На Sybase ASA кривые решения видел и они работали, но только потому, что кривую БД средних обьемов потянет любой СУБД, а на ASA биллинговых систем не пишут :)

Хорошо, согласен - это первое очевидное преимущество Оракла, но опять же на БД больших обьемов. Было бы интересно услышать плюшки применения Оракла Standart Edition в SMB в кач-ве тиражного и удаленного ПО. Тут насколько я понимаю на первом месте стоит цена решения, складывающаяся из цены СУБД, ее аппаратных требований и стоимости специалистов, далее предъявляются требования к надежности и устойчивости, нулевому администрованию и поддержки репликации без выделенных каналов связи (файлами, почтой, FTP), в случае, если консолидированная БД не является родной, то так же должны поддерживаться гетерогенные репликации. Только уж потом смотрится на функциональность, безбаговость СУБД (или хотя бы частота исправления найденных ошибок) и насколько она позволяет полноценно реализовать бизнес-логику проекта, оставляя клиентской части только простой банальный ввод данных через формочки и печать отчетов. Для многих коммерческих фирм и госконтор так же актуально поддержка защиты и криптографии данных (вплоть до уровня криптографии БД и лог-файла), так как из личного опыта могу заявить, что легче всего данные забрать с удаленных участков без админов, чем с консолидированной БД. Так же естественно нужно быть увереным в движке СУБД, что он не просядет через определенное время работы и даже при значительном увеличении данных будет продолжать самостоятельно эффективно распределять нагрузки и строить оптимальные реалистические, а не оптимистические планы запросов. С учетом новых веяний совсем неплохо иметь полную поддержку XML для передачи данных в другие современные системы и поддержку удаленных серверов для работы с устаревшими системами. Ну и для тиражного ПО в том числе важен минимальный размер инсталяции сервера, возможность легко включать сервер в инсталяцию собственного ПО, маштабируемость (например для расчета зп ПБОЮЛ считает для 5-х сотрудников зп, а некий завод "Красный серп" для 50 000 сотрудников, или в одном ДЭЗ проводиться расчет кварплаты для 8 000 лицевых счетов, а в другом считаются аж 150 000) и кроссплатформенность (раз хочет клиент поставить сервер на Windows 9x-NT, Linux или даже Novell, это его полное право).

В основном по моему все пункты перечислил, Sybase ASA с моей личной точки зрения подходит под них идеально, MSSQL под них тоже "почти" подходит, но только "почти". Было бы интересно и в хорошем плане поучительно услышать, насколько под них подходит легкая версия Оракла. Сравнение тяжелых версий оставляю специалистам по аналитическим хранилищам БД, меня особо не волнует, кто сколько и засколько террабайт обработал, так как я этими задачами не занимаюсь.

авторЕсли в Sybase они легко, быстро и без извратов решаемы, то и смысла нет с Ораклом огород городить
Угу, самое что радует, что действительно задачи абсолютно легко и без извратов решаемы стандартными средствами самой СУБД. Причем меня больше всего радует, что в этой СУБД все сделано просто и надежно, по уму и правильно: механизм блокировок, оптимизатор запросов, WatcomSQL, средства управления и администрирования сервера и средства разработки и отладки БД. И нет каких либо архитектурных или функциональных ограничений, которые пришлось бы обходить со всеми вытекающими (все таки это камень с моей стороны известно в чей огород, но тут уж ничего не поделаешь, так как это правда обидным размером в 8кб и многим многим другим, иногда даже просто непонятным).