Конвертировать - для MS SQL, самой СУБД - Enterprise Manager (имспорт/экспорт)- для Firebird, Datapump из набора Borland (Delphi/Builder). Но иной раз, проще через MS Access.По тесту.. Андрей Германович вам уже сказал подробно.. Для собственного удовлетворения - можно создать таблицу в обоих СУБД с одинаковой структурой, где бы были все (ну или большинство типов данных, особо - varchar, char, DateTime (Date, Time, TimeStamp)), ключи, индексы...Пишем клиента на Delphi (для теста), на запись, например 1 млн. записей.. для работы с обоими СУБД. Там же операции выборки, поиска..Запускаем клиента - и потом смотрим время...Очень.. очень упрощенно.. :))) На самом деле, эта проблема может влиться в довольно серьёзный проект, который сам по себе есть придмет научной работы. :)А по сути.. чисто из практики - Firebird "быстрее".. точнее, более предпочтительней... Да и бесплатен, удобен в программировании и.. сегодня не мало важно - работает почти на всех известных ОС (многоплатформенная СУБД). Я бы рекомендовал Firebird.

Хочу добавить, что измерение быстродействия лучше производить средствами самой БД. Делается таблица - TestDB(TestName,DtBeg,DtEnd,RecCount). При начале теста делается :Insert Into TestDB(TestName) values(‘Name01‘);По default записывается DtBeg - CurrentDateTimeПо окончании теста :Update TestDB set DtEnd=CurrentDateTime, RecCount=NNN where TestName=‘Test01‘;В результате мы получаем готовую таблицу из множества результатов, которую потом легко анализировать и строить графики.Например, я заполняю таблицу людей (в таблице есть индексы) пачками по 100000 записей и вижу, что производительность на каждой падает по гиперболической кривой. После перестройки индексов производительность возвращается на исходный уровень и все начинается сначала.Поэтому для исследования честнее будет не искать какие-то универсальные тесты, а взять произвольный, но подробно описать методику измерений, среду (программную и аппаратную), данные и т.д. чтобы все это можно было повторить. А уже после этого можно сравнить.Кстати, интересный тест. У меня собирается статистика посещения моих сайтов в SQL-скрипте. Соответственно автоматом загоняется в БД.И БД то небольшая - 4-5Гб, простой запрос:Select distinct http_page from VisLog order by http_page;загнал достаточно мощный сервер в ступор. файлы tmp по 1Гб начали плодится как тараканы. Короче через 2 дня пришлось остановить все.

А по сути.. чисто из практики - Firebird "быстрее".. точнее, более предпочтительней... Да и бесплатен, удобен в программировании и.. сегодня не мало важно - работает почти на всех известных ОС (многоплатформенная СУБД). Я бы рекомендовал Firebird. Да она кросс - но все же намного медленее SQL Server и Oracle. Интересен лишь тем что бесплатный.

Firebird отличается прежде всего тем, что использует стандартный SQL, чего нельзя сказать о MS SQL Server.Насчет того что Firebird медленнее чем MS SQL, то это больше из области мифов. Реальных доказательных тестов я не видел.И, наконец, в любой СУБД можно создать БД, которая будет работать как черепаха. Виктор Пырлик не даст соврать.Судя по тому, что DrakoN предложил для испытаний три БД, отличающихся только размером, он никогда не занимался такими измерениями. Для правильно построенной БД размер мало влияет на производительность.

<b>DrakoN</b>гм.. весьма спорно.. Я бы не стал так однозначно.. Оракле.. это "быстро" только при адекватной нагрузке...А вот Firebird, при равных (да и не очень, чаще преимущества в пользу MS SQL) условиях - быстрее... Это я не по "тестам" а из практики промышленных ИС говорю...Если в "+" ставить интеграцию MS SQL c Windows и наличие "родной" среды - Enterprise Manager, то, это весьма не надежный аргумент...В общем.. реально провести тесты можно только для конкретной целевой БД, на конкретной платформе - т.е. проще говоря - поставить 2 одинаковые "рабочие" БД на разных СУБД... Но.. это "цель ради цели"...Суть не в том – какая «круче», а в том, какая СУБД более оптимальный выбор в конкретной ситуации..

to Архангельский Андрей Германович в том то и дело что проводил. Я предполагаю что для всех СУБД мы будем использовать одну платформу например Win2003SP1 или Longhorn.И вот буквально пару дней назад біла возможность сравнить производительность фаерберд и МS SQL одна и та же база. Одни и те же запросы. MS SQL оказался быстрее.В своем ответе я привел ссылки на статьи с анализом производительности с учетом себестоимости продукта. Как показали професиональные всесторонние тесты. Опттимальный вариант Oracle на юниксовой платформе. Если говорить о все стороннем анализе. Почему я утверждал что размер важен.Для баз данных менее 2 гигабайт испольхззование таких систем как Oracle и MS SQL сервер просто не оправдано. При таких размерах они не дают выигрыша в производительности. Зато при размерах свыше их использование может быть оправдано. А при очень больших они пожалуй единственные кто способен справиться. Возможно вам не приходилось сталкиваться с базами размером в несколько терабайт интересно как с ними фаерберд справиться. Так же не стоит забывать что в реальных усовиях есть еще вопрос как стабильно себя ведет система если к ней подключаються тысячи пользователей. И есть ли у фаерберда штатные средства что бы блокировать данные на время транзакции с целью избежать конфликтов?Я просто с ним не работал и мало что о нем знаю поэтому воспримите последнее как вопрос.Судя по тому, что DrakoN предложил для испытаний три БД, отличающихся только размером, он никогда не занимался такими измерениями. Для правильно построенной БД размер мало влияет на производительность.Да нет влияет. Попробуйте храните базу размером 5 гб. И обработать например фаербердом MS SQL и Oracle. При условии что база одна СУБД тоже одна и есть тысячи подключений к ней. Правильно подметил Виктор Пырлик дело в нагрузках. Я предполагаю что нагрузки максимальны так как работал олько с такими системами.

http://www.tpc.org/results/individual_results/HP/tpcc.hp.SD.es.082107.pdf

to DrakoNДля сравнения производительности необходимо минимум месяцы, какой можно сделать вывод за пару дней?"Опттимальный вариант Oracle на юниксовой платформе" - это ни о чем не говорит. На производительность влияют так много факторов, что указание только на СУБД+ОС - это все равно указать как покраска салона влияет на скорость автомобиля. Например, у меня при установке 2 дополнительных HDD производительность увеличилась в 6 раз. Но в LongHorn эту возможность отрубили."И есть ли у фаерберда штатные средства что бы блокировать данные на время транзакции" - а Вы что думаете, что FireBird это игрушка для детского сада типа FoxPro? Для Вашего сведения и Oracle и Firebird вышли из одной и той же СУБД - RDB/VMS и имеют все, что необходимо для современной СУБД для нормальной работы. Познакомьтесь например с системой Avarda. Она моделирует работу распределенной БД реальной торговой фирмы с несколькими сотнями рабочих мест, с выпиской счетов, накладных и прочее - 15000 создаваемых документов в сутки, рабочая БД 150Гб. Все это сделано на FireBird.У меня в каждой БД сразу закладывается таблица для сбора данных по производительности. И любые более или менее серьезные задачи измеряются. И если говорить о поиске, то быстродействие БД в 0.5Гб и 10Гб практически одинаково. БД одна и та же, просто накопились данные.Если говорить о максимальных нагрузках, то тоже нужно определить - что это такое. Пиковые нагрузки в билинговых системах или тяжелые запросы в бухгалтерских программах. Параметры, которые влияют на производительность для этих систем совершенно разные.Кстати для справки. Первая большая БД для Interbase (предшественник Firebird) была создана хакерами для взлома паролей Interbase. Так как пароли у него взломать нельзя, то решили создать большую таблицу соответствия открытого и зашифрованного пароля. Таблица получилась небольшая - 980Гби нормально работала.

Посмотрел предьявленный документ. Если хотели впечатлить ценой этого сервера, то не получилось. А доказательства, что какая-то СУБД шустрее я там не нашел.

<b>DrakoN</b>Да.. насчет MS SQL... с ростом размера БД и количеством активных клиентов - производительность падает... Ну.. она изначально определена как система уровня предприятия..(так же как и ОС), и MS не претендует на большее...А если говорить о терабайтных БД.. или о данных очень большого размера, то на сегодняшний день это Оракле.. Для всего свой инструмент.. И не надо пытаться поставить СУБД в стрессовую ситуацию - это не тест.. Это декларация её возможностей.. и то, для узкого круга специалистов...<i>"И есть ли у фаерберда штатные средства что бы блокировать данные на время транзакции"</i> Что вы имели ввиду? "Гонки", или что? Честно говоря.. только в MS SQL 2005 частично внедрено то - что в InterBase было с самого начала - множество идей как раз и пришли от туда... ("Oracle и Firebird вышли из одной и той же СУБД - RDB/VMS" Архангельский Андрей Германович). Просто, MS SQL высоко интегрирована с Windows...Но вот по удобству как разработки/программирования, так и по сложности/стоимости использования - значительно проигрывает Firebird/InterBase (последн.версии), да и в остальном..Да и, честно говоря, терабайтные БД… не думаю что такие БД сегодня есть норма… На такие критичные нагрузки надо иначе выбор делать.. и уж точно не из «младших» систем как то MS SQL или Firebird…PS: вот.. простое – сделайте в MS SQL многовариантное условие в SELECT (без использования курсоров), попробуете написать прстенькую БД где активно бы использовались даты.. как тип DateTime – вот, хотя бы 2 этих вопроса для себя решите..

Спорить не буду. Так как дальнейший спор из категории проффесиональнного переходит в категорию философского только лишь приведу пару ссылок по теме вопроса )вот интересная статьяhttp://www.bytemag.ru/?ID=602497а вот ссылка на оффсайт компании которая занимаеться исследованиями в области производительности http://www.tpc.org/Именно оттуда был взят этот документ. Я думаю что вам будет интересно ознакомиться с данными приведенными там.RegardsMax

Да.. насчет MS SQL... с ростом размера БД и количеством активных клиентов - производительность падает... Это касаеться только 2000 и если криво писаны программы. В 2005 эту проблему решили. Я знаю о чем речь идет там было пару багов который превращали MS SQL 2000 из хорошей СУБД в жалкое подобие которое доведет до белого каления. Притом майкрософт так и не пофиксил в 2000 єти проблемы, они были устранены лишь в 2005.

Да.. спор конечно не к чему..:)На сайте http://www.tpc.org кроме явных комерчиских брендов, больше ничего нет.. Кстати, мы не упомянули IBM DB2 - то же, довольно не плохая СУБД...Кроме тестов "брендовых", есть еще и практика, она порой идет в разрез со всякими тестами...В целом, любая из систем отлично работает. А плюсы и минусы уже вроде описаны выше. Так что, моё мнение, СУБД надо выбирать под конкретные задачи на основании как требований/возможностей, так и планирования её сопровождения...PS: Ознакомившись с данным сайтом - впячетление, что больше никаких СУБД нет...

to Виктор Пырликну это не удивительно что другие не проверяли ведь такие исследования интересуют только очень большие компании. Естественно с соответствующими запросами.Все остальные выбирают из принципа у меня столько то денег на оборудование и софт. Что лучшее можно поставить. И как правило дальше MS SQL Server не идут. Так как Oracle даже при условии что хватит денег на лицензию требует двух дорогостоящих специалистов. Юниксового админа и админа для СУБД. Это не считая затрат на оборудование. Ну вот отсюда все и начинается. ...Собственно.Хотя опять же небольшим компаниям в силу того что с их базами неплохо справиться и Firebird этот материал интересен, лишь с точки зрения общего развития для Айти отдела. Вот если начальство подобреет ....Ладно пора заканчивать ) А то уже куда то не туда совсем )RegardsMax