как то не логично, или я чего то не знаю.

Мани мани манИ
есть у клани
нет уууУ фриииии

(0) Потому что mysql он используется для малых приложений, postgree будет по шустрее, подойдет для средних приложений.

Потому что читайте лицензию MySQL

(0) а в чем собственно нелогичность? PostgreSQL - опенсорс, MySQL там какое-то уг у них сейчас.

К тому же MySQL изначально для домашних страничек создавался

почему не Firebird тогда тоже

(0)не помню уж точно но вроде МайСкуль по каким-то тех. особенностям не подходил, гимора с ним много

(0) Потому что MySQL - детская игрушка.

(5) Firebird - тормоз. Простенькие запросы по 20-30 секунд пережевывает...

в mysql ни транзакция ни вложенных запросов на тот момент не было

(5) У Firebird немного другая изоляция транзакций - если есть возможность - они выполняются параллельно, но если происходит столкновение, то есть вероятность, что одна из них погибнет.
Потом, Firebird требует настройки времени блокировки транзакции, после которого, если транзакция "подвешена" (то есть заблокирована другими), то она автоматически отменяется.

MySql - это сервер для работы с текстовыми данными (в большей степени). Хранимые процедуры и транзакции в нём появились поздно, и их применение зависит от выбранной модели хранения данных.
Потом, mysql также рассчитан на параллельное исполнение, когда несколько пользователей независимо обращаются за данными в одних и тех же объектах - и не все такие обращения проходят гладко - иногда получается, что для нескольких объектов получается одно и то же значение счётчика.

Потом оба эти творения предназначены для работы с базами среднего и малого размера и даже не пытаются соревноваться с MsSql по возможностям.

Ну и ещё самое главное - в postgree есть тип UUID (то бишь Гуид), а в упомянутых выше поделках guid придётся хранить в виде строки или двоичных данных.

Firebird - почти труп. По крайней мере такое впечатление складывается, если сравнить его развитие и развитие PostgreSQL и MySQL с момента открытия кодов Interbase и по текущее время.

MySQL может и хорошая СУБД, но
1) как сказали в (10) фишки типа триггеров и хранимок появились сравнительно поздно,

2) Лично я убежден что поддержка линукса и Postgres 1С:Предприятием это ничто иное как попытка снизить зависимость от поставщика СУБД. В этом смысле Postgres предпочтительнее других Опен-СУБД т.к. реально не зависит ни от одной из Компании, динамично развивается, поддерживает все целевые платформы и т.п.

Да и вообще: PostgreSQL круче MySQL, имхо.

(11) По поводу трупа, похоже, ты не прав, по крайней мере в августе этого года они выкатили альфу релиза 3.0

(5) про это говорили, что доработают (с ошибкой ТОР), но результатов нет... похоже передумали...

В постгре все хорошо, но русскоязычной инфы по нему ну очень мало :-(, книги чуть ли не десятилетней давности, хоть бы уж 1С сподобилась и выпустила что-нибудь по постгре, если уж декларирует его поддержку

(11) "Жареный" - стабильно работает в своих местах.
Придуманная ими модель SELECT-процедуры, когда можно кодом строить виртуальную таблицу - позволяет делать Trace выполнения кода хранимки, чего в других местах просто нет.
Возможность подключать dll для выполнения своих функций тоже бывает не лишней.
Но, организация хранения транзакций у "птички" достаточно своеобразная из-за чего SELECT COUNT(*) выполняется медленнее, чем любой другой запрос, если есть открытые транзакции, так ка приводит к полному сканированию таблицы.
К сожалению, он просто совсем другой.

с постгре тоже надо аккуратным быть. тут было хотел на нем упп запустить на винде 2008. Оказалось в сотни раз медленнее чем на мс скл экспресс, с дефотными настройками. В общем фри он и есть фри.

1C хранит этот ваш GUID как binary(16) , так што мимо.

(16) С Постгри надо быть просто осторожней потому, что в нем другой порядок сортировки по умолчанию.

(10) В оракле вроде как тоже версионность, и принципы схожие.. разве что более глубокая проработка алгоритмов. Но и файрберд это не наколенная поделка, это серьезная СУБД, форкнутый интербейс, который в своё время шел в одном ряду с ораклом.. а mssql был тогда анекдотом..

(21) "Firebird это серьезная СУБД...в своё время шел в одном ряду с ораклом... а mssql был тогда анекдотом"

Жги еще!

(22) А что не так? Можно подумать, в начале 90-х microsoft sql server представлял собой что-то серьезное, а не просто примочку к аксессу для клиент-серверной работы..

(23) 1c 7.7 в каком году вышла? MS SQL 6.5 в каком году вышел?

(24) fix 1c 7.5

полуофф:
а почему в PostgreSQL не захотели сделать режима полной совместимости с MS SQL ? с той же 2000 или 2005й ?
тогда можно было бы нативно например 1С 7.7 запускать

(26) А зачем это разработчикам постгреса? У них своё видение пути развития, они ему следуют.. им ни к чему копировать mssql.

(12)(15) Ну да... вероятно я не прав.

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

(29) есть конкретные примеры того,  что "работа движка 1С со скулем через задницу организована"?

(29) Не знаю, не анализировал запросы с движка, за исключением редких случаеа. А надо?
(30) Вероятно, имеется в виду, что нет SP, функций и пр.

Вообще-то, действительно, все обсуждаю какие-то тригеры, хранимые процедуры. Где все это в 1С?

Я правильно понимаю, что (29) пукнул в лужу и сЪебался?

(33) Не знаю, как там в лужу, но в (19) уже сказано.
Кстати, в mysql и binary криво реализован, что по нему индексирование невозможно.
(22) Смеяться не надо, firebird действительно умеет много чего интересного - например, транзакции, по умолчанию, сразу пишутся в файл, а не хранятся в памяти. Ещё есть возможности по управлению планами выполнения запросов, но это для тех, кто любит всякие интересные вещи.
И ещё - firebird заточен под работу на системах, где возможно аварийное завершение по отключению питания - он от этого не мрёт, а если и мрёт, то легко оживает - все остальные SQL-сервера в таком режиме обычно сразу медным тазом накрываются вместе с данными (особенно Postgree).

Torquader ты женат что ли на firebird?
Что ты так распинаешься за него...

(35) На этой СУБД редко женятся, да и просто постоянные отношения редко встречаются - но поклонников-вздыхателей у неё достаточно)

(35) Просто у меня были сайты с базами на PostGree, MySql и FireBird.
Вот сайт с базой на PostGree после остановки виртуальной машины умер безвозвратно, и никакие утилиты его не смогли поднять - пришлось разворачивать резервную копию.
Firebird в такой ситуации с помощью стандартной утилиты прекрасно поднимался.
Ну, а MySql вообще ни разу не упал, слава богу. Ну и phpmyadmin позволяет работать с SQL без командной строки.

(37) И о чем такое сравнение?

(38) Сравнение ни о чём - понятно.
Просто, если FireBird оптимизирован под отказы и выключения питания, то под быструю работу он же не оптимизирован.

(16) либо настроено неправильно,  либо 1с так с ним работает. У меня работает не медленнее MSSQL (не 1С)

(39) у постгри тоже есть настройки,  которые такое предотвращают

(40) Объемы маленькие вот и работает так же.
На больших объемах MS SQL сделает PostGres как не фиг делать.

(0) думаю, что ответ можно прочесть в лицензионном соглашении mysql

(30) я бы сказал, что поля составного типа через жо*пу реализованы, но я не могу сказать, как надо было бы, чтобы было лучше и при этом сохранился бы уровень абстракции от СУБД во встроенном языке

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

(45) Там немножко не так, просто данные в неподтверждённой транзакции уже числятся в базе, но с признаком, что они ещё не готовы.

(46) Одно другому не мешает, хранение версий непосредственно в страницах данных и уборка мусора читателями.

(0) Вероятно потому, что MySQL не обладает необходимым функционалом.
(10) "Другая изоляция транзакций". Хаха. Да, версионник работает по-другому, но к изоляции это отношения не имеет. (21) В оракле нет версионности, вернее, есть, но их (версий) аж целых две. Принципы функционирования сравнивать некорректно.
(45) Нет, не обязан. И даже можно вообще их никогда не чистить, хотя это очень частный случай.
(46) Признак "неготовности" у транзакции, а не у данных. Данные уже записаны.

(48) Вот здесь всё доступно написано про реализацию версионности в IB/FB, из этого понятно, почему в этом сервере нет понятия "журнал транзакций"..
http://www.ibase.ru/devinfo/mga.htm

(49) Вы на какой-то мой вопрос отвечаете? Или просто так ссылку привели?
Наличие журнала транзакций в СУБД никак не влияет на работу 1С с ней.

(50) Это я на тему некоего "признака неготовности", который непонятно откуда берется.. ибо никакого такого признака нет, а есть версия, актуальная или неактуальная..

(3) лицензия ни при чём (хотя конечно при чём, но не главное) важен функционал которого нет в мускуле но есть в постгри..

(51) Прочитайте приведённую вами же ссылку. "Признак неготовности" определяется состоянием транзакции в TIP.
И нет никакой "актуальной версии", все подтверждённые транзакции актуальны в той или иной мере.

(53) Для вновь стартовавшей транзакции актуальны только те версии, которые были закоммичены на момент её старта. Остальные она не видит, для неё их не существует. При этом никаких блокировок..

(54) Уже лучше. Теперь вспомните об уровне изоляции транзакций, и больше не пишите "остальные она не видит" без дополнительных уточнений.

P.S. Я немножко разбираюсь в теме, прошу вас воздержаться от дальнейшего цитирования мне теории.

Там всё немного сложнее, так как уровень изоляции транзакций можно менять - можно заставить транзакцию видеть неподтверждённые данные, но у FireBird это получается криво.
Кроме того, при изменении уровня изоляции происходит блокировка транзакции, когда она ожидает подтверждения изменения данных.

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

А ещё - в FireBird есть события, когда сервер может "пнуть" клиента и сообщить ему, что что-то нужно делать. Благодаря этой возможности сервер может делать вызовы кода клиента, что в других SQL-серверах невозможно (да и противоречит идеологии SQL).

(55) Разумеется, речь идет об уровне snapshot, единственном, заслуживающим внимание, ибо он наиболее логичен на версионнике. А ублюдочный read commited в топку..)
(56) "получается, что у FireBird как таковых уникальных индексов нет - могут существовать разные записи в разных транзакциях с одним и тем же значением поля"
Кому это мешает? При снапшоте всё равно эти грязные данные никто не видит.. а при попытке коммита вылетит исключительная ситуация нарушения констрайнта.

Может быть при выборе СУБД имело значение и наличие определенного инструментария, необходимого для разработки, отладки и тестирования. А такой инструментарий на момент принятия решения(примерно 2006 год) уже был у EnterpriseDB(основана в 2004-ом). Плюс спонсорами/инвесторами являются IBM, RedHat и некоторые другие, и в то же время они себя представляют относительно независимой компанией. И десять лет она вполне успешно развивается, без особых потрясений, являясь своеобразным звеном межу постгрес комьюнити и большим бизнесом.
Не знаю как в действительности идет процесс разработки того же сервера приложений, но не думаю, что кто-то тупо в командной строке psql набирает explain analyze и далее 20 кб текста запроса, который нужно "отаналайзить".
http://habrahabr.ru/post/137183/
http://www.pcweek.ru/its/article/detail.php?ID=136604

MySql кто-нибудь где-нибудь кроме Web приложений использует ?
Потом, MySql не совсем бесплатный:
https://shop.oracle.com/pls/ostore/product?p1=MySQL

(57) Там есть два уровня:
SNAPSHOT и SNAPSHOT TABLE STABILITY
второй более интересен, так как блокирует изменения таблиц, прочитанных транзакцией - этот режим для 1С очень даже подошёл бы, только блокировки - это то, с чем борются.
Блокировка устанавливается через параметр WAIT - можно указать, что нужно ждать обновления версии, если она есть (не подтверждённая) или сразу выдать ошибку (что не готово).
Если транзакция READ_COMMITED, то она читает последнюю подтверждённую версию, но, опять же, если есть неподтверждённая, то будет или ожидание или ошибка.
Причём, насколько следует из текста описания - транзакция блокирует сразу всю таблицу, а не отдельные записи в ней.
В результате, получается, что одновременной работы, как таковой не будет.

(60) А почему чистый неблокировочный снапшот нельзя применить для 1с?

(61) Потому что он читает "вчерашний день" - если мы что-то из него будем изменять, то с большой вероятностью напоремся на то, что кто-то уже изменил запись.

(62) Я не вижу здесь проблему. Пока транзакция не подтверждена, нет никакого смысла в её результатах. По сути, проблему актуальности данных нужно реализовывать на более высоком уровне - на уровне бизнес-логики. Сделали же в 1с управляемые блокировки.. тож костыль, если подумать.

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

(63) У "птички" блокировки на уровне таблиц или на уровне неподтверждённых записей (если READ_COMMITED выбирать).
Получается, что управляемых блокировок там просто нет.

(64) Зачем вообще нужны блокировки? Я так понимаю, что блокировки в 1с придуманы не от хорошей жизни, а так сказать исторически. Поскольку сначала были dbf-базы, mssql без поддержки версий.. а изоляцию транзакций нужно было как-то обеспечивать. Если бы изначально 1с разрабатывалась под версионник - возможно, в ней было бы многое реализовано иначе..

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

Сейчас посмотрел, что умеет MySql - надо сказать, что InnoDB Научилась не только транзакциям, но и ведению журнала операций для восстановления после сбоя.
Собственно, там и события появились, только их нужно специально "настраивать" - и, в отличие от FireBird в MySql "события" это таймеры, которые сами по себе срабатывают и что-то выполняют - очень, кстати, полезная "фича".

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

(67) Так это и отслеживается блокировками - если блокировок нет, то в базу все пишут, как получается - и запись будет записана тем, кто был последний.
Просто, блокировки могут быть внутри SQL-сервера, а могут быть на уровне приложения.
Например, в 1С нет смысла блокировать табличные части объектов на запись, если мы заблокировали на запись основную таблицу объекта - а SQL-сервер при выполнении записи заблокирует все таблицы, так как он не знает, что в нескольких таблицах живёт один и тот же объект.

(68) "если блокировок нет, то в базу все пишут, как получается - и запись будет записана тем, кто был последний"
В версионнике при уровне изоляции snapshot вроде наоборот - победит первый, кто сделает коммит, а последующие наткнутся на конфликт версий..

(69) Так конфликт версий - это или блокировка или вылет.
Насколько я помню, в 1С Записать не возвращает код успеха, то есть придётся такие вещи ловить исключениями.
Собственно, изоляция SNAPSHOT устанавливает блокировку на записи в таблицах, чтобы система могла отследить момент другой записи.
На самом деле, нормальный SQL-сервер ставит блокировку на уровне записей и точно также - это просто "пометка" - блокировкой она называется только потому, что блокирует выполнение других транзакций.

(70) Блокировка данных и неуспех транзакции из-за конфликта - вещи разные. При блокировке одна транзакция "притормаживает" другую, а при конфликте в случае версионника происходит откат "неуспевшей" пишущей транзакции. Разумеется, в приложении это нужно отслеживать. Всё-таки, есть огромный плюс снапшот-версионника в том, что он никогда не блокирует чтение.. то есть, конфликты возможны лишь между писателями, а читатели при этом имеют полный доступ к консистентному состоянию базы на момент начала их транзакций. То есть, для одновременной работы OLAP и OLTP версионники наиболее подходящи..

(71) SNAP_SHOT хорош для выполнения отчётов, когда хочется иметь данные на какой-то момент времени.
А вот при записи лучше открывать READ_COMMITED, чтобы транзакция ждала, пока отработают другие.

(0) Патамушта программист, который писал эту программку, решил первой выбирать именно это хранилище... видимо фанат линукса и прочих бесплатных приложений

(72) Ну тогда лучше некий компромиссный вариант.. чтобы писатели блокировали писателей, а читатели работали со снапшотом. Интересно, в каком sql-сервере это реализовано?

ну вот и постановили!

Torquader, Chai Nic, откуда вы такую траву берёте?

НЕЛЬЗЯ заставить транзакцию видеть неподтверждённые данные. Кроме своих собственных изменений, разумеется, но это в любой СУБД, иначе чушь получится.

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

EVENT ничему не противоречит, и никакого клиентского кода сам по себе не вызывает. И в упомянутом тут Oracle он тоже есть.

Чтение данных в версионнике НЕ БЛОКИРУЕТСЯ никогда, ни в каком уровне изоляции транзакции (кроме режима FOR UPDATE WITH LOCK). Изменение данных блокирует всегда построчно, кроме странного режима блокировки всей таблицы, который Torquader упомянул, но никто его не использует, поскольку в версионнике не даёт никаких преимуществ, только минусы. И никакой эскалации блокировок нет, поскольку архитектура версионника так работает.

(76) Я не понял, где я утверждаю то, что вы мне приписываете?

(77) Вам конкретно я ничего не приписал, описал только диалог в целом, хотя конечно подавляющее количество чепухи написано Torquader.
Конкретно у вас я бы оспорил фразу "Разумеется, речь идет об уровне snapshot, единственном, заслуживающим внимание, ибо он наиболее логичен на версионнике. А ублюдочный read commited в топку.", но потом подумал, что холивар тут устраивать не место, и писать не стал.

(5) - патамушта лицензия

и вообще, реальных специалистов по Firebird - 3 с половиной человека. В отличие от PostgreSQL

(78) Чувствуется, вы в теме. Скажите в двух словах, чего не хватает файрберду, чтобы стать ораклом?)

(80) - у Firebird подпорченная репутация

"несерьезно", "автоматизация на коленках", "ее используют нищебродские фирмы", "туда никто не идет", "дебильное руководство фирм, использующее эту СУБД", "ЭЛТ мониторы 15 дюймов", "старые компы с 64 Мб RAM", "нет денег на новое железо"


Продолжить?

и да, самое страшное это то, что те, кто внедряет/использует Firebird, думают, что они внедряют Oracle. Со всеми вытекающими. Нувыпонели.

(80) Если бы FB нужно было становиться ораклом, зачем он вообще нужен? Есть разные задачи или условия, для которых оракл подходит хуже, чем FB.
Мне вообще странны утверждения, что должна быть одна супер-СУБД для всего на свете.

(81) у 1С подпорченная репутация. "несерьёзно", "автоматизация на коленках", "ее используют нищебродские фирмы", ...
Ну, вы поняли.

(0) В принципе могло выбрать все что угодно .  Все заявленные СУБД  в отличие от MSSQL имхо  рекламный ход  не более  или если есть уже корпоративная СУБД  типа Oracle чтоб туда же 1С поставить. Т.к. 1С заточено по скуль .

(76) Что касается Read Uncommited, то FireBird этого не умеет - он умеет только блокировать запись или чтение, если есть неподтверждённые записи.
А вот у MySql в InnoDB как раз есть режим Read Uncommited, позволяющий увидеть неподтверждённые записи другой транзакции (у них сказано, чтобы можно было "мягко" на программном уровне обойти блокировки).

Что касается чтения, то само чтение ничего не блокирует, но напарывается на блокировки, произошедшие из-за изменения данных другими транзакциями (если мы ставим режим ReadCommited).
А, если говорить о FireBird, то у него блокирование реализовано только на табличном уровне (можно заблокировать таблицу и всю), а остальное разруливается не самим блокированием, а возможностью существования нескольких версий одной записи.
Опять же, в транзакции можно указать WAIT или NO WAIT, чтобы или ждать какое-то время окончания транзакции, которая ещё изменяет данные или сразу выйти с ошибкой.

(81) У firebird вполне нормальная репутация - не забываем, что для Ebedded-систем есть MSSQL-Embedded или MySql-Embedded-Edition.
FireBird так и не познакомился с полнотекстовым поиском, а также не научился работать с GUID-ами. А про распределение и кластеризацию он вообще не слышал.
Вопрос в том, почему нельзя было использовать FireBird-internal для файлового режима работы (не забываем, что у FireBird есть режим работы, когда для каждого приложения создаётся свой экземпляр сервера).

И вообще - это "жареное чудо" выключает индекс при обнаружении ошибки индексирования, при этом не выдавая ошибку - то есть всё как бы продолжает работать, но запросы без индекса выполняются существенно медленнее.

(85)

"FireBird так и не познакомился с полнотекстовым поиском"
Для 1с неактуально - в ней он реализован на уровне платформы, без использования спецсредств СУБД.

"не научился работать с GUID-ами"
Опять же, 1с хранит гуиды как бинарную строку, так что нет необходимости.

"про распределение и кластеризацию он вообще не слышал"
1с опять же реализует это на уровне платформы.

"Вопрос в том, почему нельзя было использовать FireBird-internal для файлового режима работы"
А вот в этом вообще смысла нет никакого. Файлового режима не должно было быть вообще, за исключением однопользовательских базовых версий..

(86) А почему не SQLlite?

(85) - у Firebird очень плохая репутация на Западе - ее там почти не знают. А чего ожидать от системы, разрабатываемой для военных?

(88) "А чего ожидать от системы, разрабатываемой для военных?"
Наоборот, это было бы дополнительным конкурентным преимуществом) "Наша система настолько надежна, что её используют для хранения параметров полета стратегических ракет" - как-то так..)

(89) - грибы откуда брал?

(85) Чтение в firebird заблокировать нельзя. Версии записей ничего не блокируют. Записи блокируются при изменении, никаких  "разруливается не самим блокированием".
"выключает индекс при обнаружении ошибки индексирования" - поржал. Тут и так оффтопика навалом, давайте перейдём в ветку http://www.sql.ru/forum/interbase, мне хочется услышать от вас о том, как сервер обнаруживает ошибку индексирования.

(88) В Бразилии, к примеру, вполне себе знают, и конференции проводят. Куда уж западнее.

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

(92) Индекс в состояние INACTIVE переходит при восстановлении базы из бэкапа, если его (индекса) создание вызывает ошибку. Например, две неуникальных записи в уникальном индексе. Откуда они взялись в бэкапе - это отдельный вопрос.
Но всё же это никак не ошибка индексирования.

(93) С общем, там всё именно так и происходит, при выключении машины система оставляет метку, что её не вовремя срубили.
При включении, "умная программа" подключает базу данных и что-то в ней восстанавливает, хотя в журнале было написано только восстановление незаконченных транзакций - и опа - в таблице базы две одинаковых записи (просто одинаковых).
Если делать BackUp, то это видно.
Другое дело, что индекс уже становится INACTIVE после того, как "умная программа" сделала восстановление базы.

Кстати, при восстановлении из бекапа "птичка" поражает способностью - она сначала создаёт все индексы в состоянии inactive, потом грузит данные, и только потом "включает" индексы - интересное решение.

Ладно, в общем, "птичка" вполне хорошая.
А вот MySql, похоже, теперь у Oracle под крылом:
http://www.oracle.com/us/products/mysql/overview/index.html
То есть теперь внедренцы MySql могут говорить, что они работают с Oracle.

по поводу блокировок в птичке все есть:
http://www.ibase.ru/devinfo/plocks.htm

(94) "она сначала создаёт все индексы в состоянии inactive"
Это просто объявление метаданных, индекса в состоянии inactive считай нет.
"включение" индексов собственно является их созданием.
Соответственно, при "выключении" индекс просто удаляется, поскольку становится невалидным, и при обратном "включении" он должен построиться заново.

(96) Так оно и есть. Просто индекс можно сразу создать в режиме Active, но для удобства - создают в Inactive.
Вообще, FireBird любит работу в два этапа - Prepare и Execute.
Кстати, в отличие от MySql даже в том же php получается возможность пихать в базу всё, что угодно, без всяких танцев с бубнами вокруг указания части запроса в переменной.
(95) Это по поводу блокировок в MySql можно сказать - там только второй механизм и был.

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

(97) На момент объявления индекса данные ещё не залиты, потому строить его не по чему.

(98) И что же именно не поддерживается?

(99) Я на днях почитал инструкцию по MySql - в новом есть встроенный шедулер, который может исполнять код периодически, причём событий может быть несколько.
Режим доступа к удалённым базам (когда описание базы хранится локально, а за данными нужно подключаться к другой базе).
В общем, после внимательного чтения возникает желание "птичку" запихать куда-то подальше.
P.S. и функции, определяемые пользователем в MySql тоже есть.
Нету, конечно, SELECT-процедур, но без них можно обойтись.

(100) В чём преимущество встроенного шедулера перед стандартным ОС?
Можешь запихивать, я не возражаю.
И переходить на MySQL, с ограничением в 61 таблицу в запросе типовая база, пожалуй, и не взлетит в 1С. И с транзакциями у них по-прежнему какая-то фигня.