Сравнение Pervasive и MSSQL
Модераторы: m0p3e, edward_K, Модераторы
-
- Постоянный гость
- Сообщения: 93
- Зарегистрирован: 25 май 2006, 17:57
- Откуда: ООО "Эфес", г. Пермь
- Контактная информация:
Сравнение Pervasive и MSSQL
Плиз, киньте пару ссылочек или подскажите где посмотреть. Интересуют преимущества и недостатки того и другого, когда что целесообразно использовать а когда нет
-
- Местный житель
- Сообщения: 1844
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Ярославская область ОАО "Часовой завод Чайка" г. Углич
- Контактная информация:
Могу сказать по своему опыту...преимуществ у BTRIEVE практически нету по сравнению с MSSQL. Первый целесообразно использовать лишь когда объем данных небольшой потенциально.
Преимущества BTRIEVE :
- относительно MSSQL легче в администрировании и настройке ;
- пожалуй еще плюсом (а может и минусом ) является то, что хранение 1 таблица- 1 файл. Удобно бывает при некоторых манипуляциях с БД.
В остальном (самом критичном ! ) MSSQL лучше:
- внутренние оптимизационные механизмы, влияющие на скорость работы с БД;
- безопасность;
- написаний приложений сторонних, так или иначе работающих в этой БД ;
Преимущества BTRIEVE :
- относительно MSSQL легче в администрировании и настройке ;
- пожалуй еще плюсом (а может и минусом ) является то, что хранение 1 таблица- 1 файл. Удобно бывает при некоторых манипуляциях с БД.
В остальном (самом критичном ! ) MSSQL лучше:
- внутренние оптимизационные механизмы, влияющие на скорость работы с БД;
- безопасность;
- написаний приложений сторонних, так или иначе работающих в этой БД ;
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
Я бы сказал что с релизом 8.10 у сиквела только минусы..
Быстродействие точно не выше, хотя надо тестить как следует.
Ну жу точно не земля и небо..
Разве что безопасность...
НО:
1. Надо держать админа сиквела, а это расходы. тем более что путевый админ стоит не дешево..
2. Видел разок слетевший файл индексов под сиквелом. Беда, короче. А в первазиве рекавер.бат и все путем. На порядок легче восстанавливать...
3. Любая безопасность имеет свои границы. Безопасность чего? Данных. Так их стырить не фиг на фиг и с сиквелом и с чем угодно.
Построил пару отчетов за весь период на флешку и грош цена такой безопасности.
Быстродействие точно не выше, хотя надо тестить как следует.
Ну жу точно не земля и небо..
Разве что безопасность...
НО:
1. Надо держать админа сиквела, а это расходы. тем более что путевый админ стоит не дешево..
2. Видел разок слетевший файл индексов под сиквелом. Беда, короче. А в первазиве рекавер.бат и все путем. На порядок легче восстанавливать...
3. Любая безопасность имеет свои границы. Безопасность чего? Данных. Так их стырить не фиг на фиг и с сиквелом и с чем угодно.
Построил пару отчетов за весь период на флешку и грош цена такой безопасности.
-
- Местный житель
- Сообщения: 1844
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Ярославская область ОАО "Часовой завод Чайка" г. Углич
- Контактная информация:
Точно не выше ?...интересно откуда такие выводы.
Простая процедура выборки данных при отсутствии нужного индекса на битриве весьма и весьма не быстра. Если в таблице n-миллионов записей то разницу во времени здорово ощутите на btrieve и sql базе при неидексном селекте. А так приходится идти по пути переиндексации всех нужных вариантов ,как это реализовано в Галактике..иначе получим страшные тормоза. А такой подход не есть хорошо.
Простая процедура выборки данных при отсутствии нужного индекса на битриве весьма и весьма не быстра. Если в таблице n-миллионов записей то разницу во времени здорово ощутите на btrieve и sql базе при неидексном селекте. А так приходится идти по пути переиндексации всех нужных вариантов ,как это реализовано в Галактике..иначе получим страшные тормоза. А такой подход не есть хорошо.
-
- Местный житель
- Сообщения: 1844
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Ярославская область ОАО "Часовой завод Чайка" г. Углич
- Контактная информация:
Вот вот..вы правильно сказали все. Галактике то по барабану, поскольку она интерпретирует свои тупые запросы СУБД при таких случаях и фактически таскает на клиента каждую запись для проверки условия. Дело здесь не только в Галактике - дело в самом BTRIEVE он похоже не умеет по другому. А PERVASIVE это просто похоже красивая надстройка над BTRIEVE (могу ошибаться, но на первый взгляд именно так...). А сама работа с данными,реализованная с помощью BTRIEVE-API функций, похоже осталась таже самая. Специально конвертил рабочую здоровую базу и запускал идентичный запрос из PSQL-command и SQL QA (MSSQL). Разница по скорости выборки весьма существенная.
Поэтому и приходится иногда переписывать некоторые, уже написанные в штатном функционале вещи Г, на TSQL. И все это дело вызывать из Галактики. Разница, надо заметить, по времени отработки бывает на порядки. ПОэтому говорить о том,что BTRIEVE почти не уступает по производительности MSSQL все же рановато. А тем временем это один из самых важных показателей характеристик СУБД.
Поэтому и приходится иногда переписывать некоторые, уже написанные в штатном функционале вещи Г, на TSQL. И все это дело вызывать из Галактики. Разница, надо заметить, по времени отработки бывает на порядки. ПОэтому говорить о том,что BTRIEVE почти не уступает по производительности MSSQL все же рановато. А тем временем это один из самых важных показателей характеристик СУБД.
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
Я говорю исключительно о функционале Галактики а не самой СУБД в принципе.
Не кто не оспаривает здесь сами СУБД между собой (факты очевидны что SQL лучше).
Самой Галактики без разницы какая СУБД вот в чем самое главное.
И единственый плюс в быстродействии при использовании непосредственно TSQL это я считаю не показатель.
Ну скажем соберите мне десяток бюджетов и сравните их при помоши TSQL.
Скажу вам придется попотеть.
Да и вот еще что. На быстродействие не всегда влияют только наличие индекса или его отсутствие.
Как правило это не эргономичное использование БД самими же пользователями. Порой люди не знаю что им со всеми этими таблицами делать.
Ну например:
1. не правильная организация аналитики на счетах БУ. Часто главбухи дублируют на счетах аналитику, которая прекрасно видна на корреспондирующих счетах. То есть правило двойной записи не то что не соблюдается а напрочь перечеркивается и от него остается только наличие Д и К.
2. не правильная организация каталога МЦ
3. Дублирование информации (это как пить дать)
4. и прочее прочее
Не кто не оспаривает здесь сами СУБД между собой (факты очевидны что SQL лучше).
Самой Галактики без разницы какая СУБД вот в чем самое главное.
И единственый плюс в быстродействии при использовании непосредственно TSQL это я считаю не показатель.
Ну скажем соберите мне десяток бюджетов и сравните их при помоши TSQL.
Скажу вам придется попотеть.
Да и вот еще что. На быстродействие не всегда влияют только наличие индекса или его отсутствие.
Как правило это не эргономичное использование БД самими же пользователями. Порой люди не знаю что им со всеми этими таблицами делать.
Ну например:
1. не правильная организация аналитики на счетах БУ. Часто главбухи дублируют на счетах аналитику, которая прекрасно видна на корреспондирующих счетах. То есть правило двойной записи не то что не соблюдается а напрочь перечеркивается и от него остается только наличие Д и К.
2. не правильная организация каталога МЦ
3. Дублирование информации (это как пить дать)
4. и прочее прочее
-
- Местный житель
- Сообщения: 1844
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Ярославская область ОАО "Часовой завод Чайка" г. Углич
- Контактная информация:
Просто автор топика, такое впечатление, что просто про СУБД справшивал (вернее их разлиичия спрашивал...), некасательно Галактики вообще )Seybukan писал(а):Я говорю исключительно о функционале Галактики а не самой СУБД в принципе.
Угу. А Вы вот это скажите пользователю конкретному,когда у него до этого формировался отчет 1 час ,грубо говоря, а после переписания его на SQL стал формироваться не больше 10 минут. Боюсь, трудно будет что ли в противовес ему сказать, тем более пользователю )))Seybukan писал(а): И единственый плюс в быстродействии при использовании непосредственно TSQL это я считаю не показатель.
Мы все же старались тут приводить объективные факторы. А пользователи конечно это отдельная песняSeybukan писал(а): Как правило это не эргономичное использование БД самими же пользователями. Порой люди не знаю что им со всеми этими таблицами делать.
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
Ну это тока из-за того что не умеет Галка напрямую работать.Да...это самое главное и самое плачевное на сегодняшний момент
пока не умеет
Но есть самая большая не оспаримая прелесть.
Это то что Галактика началась когда билли под стол пешком ходил
И не факт что сиквел переживет Галку. Например бил поймет что хватит ему уже его продавать. И фсе - тушите свет.
И галактические отчет на другой СУБД будут работать, а вот написаные на конкретной СУБД просто умрут. Но это так от бред конечно.
Ну и еще раз повторить что все это пока, а что будет завтра?