Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
kmike
Member

Откуда:
Сообщений: 286
Биллинг на MSSQL? Однако...
6 мар 06, 18:24    [2422821]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
пл скл
Guest
ASCRUS
выйдет 10-ка, тогда и увидим, благо конец 1 квартала не за горами (если не обманут, как MS).


А что Оракл 10 ещё не вышел? Или что вы имете ввиду?
6 мар 06, 18:31    [2422871]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
пл скл
ASCRUS
выйдет 10-ка, тогда и увидим, благо конец 1 квартала не за горами (если не обманут, как MS).


А что Оракл 10 ещё не вышел? Или что вы имете ввиду?

Вышел. Давно при чем и достаточно неплохой, хотя народ еще предпочитает сидеть на 4-ом паке 9-ки (могу и ошибаться в цифрах, паки Оракла не считаю, своих хватает) :)
6 мар 06, 18:35    [2422885]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Oracle 10.1.0.4 уже считается вышедшим на качество продакшн. У нас вот стоит на боевом посту. Вышел сервис-пак к версии 10.2 - скоро и её начнут в продакшине применять.

Если вы такие отчаянные ребята, что готовы использовать бесплатные версии БД, то напомню, что есть ещё и бесплатный Oracle XE (limits 1CPU, 4GB of data)
Но я бы поостерёгся бесплатности.

Да, при подсчёте стоимости учтите, что вторую БД (standby) надо тоже покупать.

Ах да, у Оракла можно построить кластер, в котором падение одного из узлов происходит незаметно для пользователя ;). То есть сессия подхватывается выжившим узлом. Вам может понравиться эта фича ;)

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

--
Антон
Per rectum ad astrum
6 мар 06, 19:12    [2423035]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.


Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре)
6 мар 06, 20:00    [2423202]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Выбегалло
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.


Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре)

А сколько стоит Informix, есть ли модная версия Express ?
6 мар 06, 20:07    [2423223]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.
Как недавно плотно занимавшийся ознакомлением DB2 скажу:
DB2- база хорошая, но посмотрите для себя внимательно следующее:
1) Посмотрите как и чем вы с ней будете работать. Инструментария мало и он не удобен.
2) По сравнению с другими, плохая поддержка UNICODE.
3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.
4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.
5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо.
6 мар 06, 21:11    [2423354]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Leonid
3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.
Вернее в MSSQL они настраиваемые.
6 мар 06, 21:20    [2423373]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Leonid
Leonid
3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.
Вернее в MSSQL они настраиваемые.

в DB2 есть настраиваемые таблицы сортировки как раз для этого случая. Но об этом я знаю только теоретически, как на практике - не знаю.
Вот ссылка на примере iSeries, где рассказывают про collating sequences.
6 мар 06, 21:41    [2423403]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
1024

при такой постановке лучше взять то что знаешь.

В соседней ветке посмотри, про
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)


Не надо относиться к ним так уж серьёзно. Интерес в них в лишь том, что можно поковыряться лично и позадавать вопросы самому себе, почему так получилось и нельзя ли что-то ускорить.
6 мар 06, 22:35    [2423494]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Leonid
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.
Как недавно плотно занимавшийся ознакомлением DB2 скажу:
DB2- база хорошая, но посмотрите для себя внимательно следующее:
1) Посмотрите как и чем вы с ней будете работать. Инструментария мало и он не удобен.

Ну, это вещь субъективная.

2) По сравнению с другими, плохая поддержка UNICODE.

В чём?

4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.

В чём?

5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо.

Я полагаю, это очень легко сделать, если приспичит (и вы дружите с C).
6 мар 06, 22:44    [2423509]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Выбегалло
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.


Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее


Откуда вам такое известно? И это верно на любых конфигурациях и запросах?
6 мар 06, 22:50    [2423521]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Anton Demidov
Leonid
Leonid
3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.
Вернее в MSSQL они настраиваемые.

в DB2 есть настраиваемые таблицы сортировки как раз для этого случая. Но об этом я знаю только теоретически, как на практике - не знаю.
Вот ссылка на примере iSeries, где рассказывают про collating sequences.

Увы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД.
6 мар 06, 22:52    [2423528]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Victor Metelitsa
Увы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД.

То есть ты хочешь сказать, что это фича AS/400 ?
6 мар 06, 22:55    [2423542]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
ASCRUS
Выбегалло
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.


Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре)

А сколько стоит Informix, есть ли модная версия Express ?


Express есть, но в экспрессе нет репликации.
Сколько стоит - не знаю, как обычно, надо торговаться.
6 мар 06, 23:06    [2423576]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Anton Demidov
Victor Metelitsa
Увы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД.

То есть ты хочешь сказать, что это фича AS/400 ?


Да.

Понятно, где эти таблицы лежат (SQLLIB\conv), и IBM предлагает их менять самим в некоторых случаях в качестве workaround'а на другие готовые (четыре штуки SQLLIB\conv\ms), но создать самим не позволяют, и готовых нечуствительных к регистру для русских нет.

Что не означает, что проблема совсем уж неразрешима. Можно использовать generated-колонки (что, в свою очередь, в данном применении workaround к отсутствию индексов по выражениям).
CREATE TABLE xxx(
  fff VARCHAR(100),
  u_fff GENERATED ALWAYS AS (translate(ucase(fff), 'Е', 'Ё'))
...
);
CREATE INDEX ... (u_fff, ...) ...;
SELECT ... 
WHERE (translate(ucase(fff), 'Е', 'Ё'))=(translate(ucase(:SOMEVAR), 'Е', 'Ё'))
ORDER BY (translate(ucase(fff), 'Е', 'Ё'));
6 мар 06, 23:07    [2423579]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Victor Metelitsa
Выбегалло
Random_Goodman
Че-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.


Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее


Откуда вам такое известно? И это верно на любых конфигурациях и запросах?


называется "anecdotical evidence" - поскольку поучаствовать в TPC Информикс не пускают. От работников саппорта, которые раньше занимались informix_ом а теперь DB2.
нет, не на любых запросах - обязательно найдется хоть один запрос, который на СУБД А выполняется дольше, чем на СУБД Б, при любом значении А и Б.
6 мар 06, 23:11    [2423588]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
По сообщению агентства ОБС, т.е.
6 мар 06, 23:12    [2423589]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Victor Metelitsa

Leonid
2) По сравнению с другими, плохая поддержка UNICODE.

В чём?
Это разве не ваши слова:
Victor Metelitsa
Хм. Посмотрел в CREATE TABLE:

# Tables created with CCSID UNICODE cannot be referenced in SQL functions or SQL methods (SQLSTATE 560C0).
# An SQL statement that references a table created with CCSID UNICODE cannot invoke an SQL function or SQL method (SQLSTATE 53090).
# Tables cannot have both the CCSID UNICODE clause and the DATA CAPTURE CHANGES clause specified (SQLSTATE 42613).
# Declared global temporary tables cannot be created with CCSID UNICODE (SQLSTATE 56031).
# SQL statements are always interpreted in the database code page. In particular, this means that every character in literals, hex literals, and delimited identifiers must have a representation in the database code page; otherwise, the character will be replaced with the substitution character.

Не вдохновляет.
Если взять тот же MSSQL, то там работа с (char/nchar)(varchar/nvarchar) (text/ntext) (varchar(max)/nvarchar(max)) практически прозрачна.

Victor Metelitsa
Leonid
4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.
В чём?
Для того чтобы написать хранимку под win мне пришлось поставить старый VS, поскольку от VS2005 Си-шный nmake не подходил. Это может и фигня, но фактически SQL-льные хранимки в DB2 это жестко-платформенно откомпилированные модули. Разве не так?
В кросплатформенном Оракле нет необходимости такой компиляции процедур на PL/SQL (хотя она и возможна), а на T-SQL и подавно. И они будут переносимы с версии на версию и с сервера на сервер с минимальными телодвижениями.

Victor Metelitsa
Leonid
5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо.

Я полагаю, это очень легко сделать, если приспичит (и вы дружите с C).
Под win не сложно, под Linux немного сложнее. Я, например, не знаю точного алгоритма создания GUID. Попробуйте найти и создать, если хотите.
В любом случае, это не будет так просто, как встроенный тип.
Но опять же повторюсь, далеко не всем это надо.
6 мар 06, 23:38    [2423637]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Цитаты про unicode относятся про случай unicode-строк в не-unicode базе. В unicode базе дела обстоят по-другому.

Хранимые процедуры в DB2 8.2 совсем не обязательно писать на C, и они переносимы.

Уверен, что для генерации GUID где-нибудь в интернете найдётся готовый код.
7 мар 06, 00:13    [2423683]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Да SP и на C переносимы (см. SQLLIB\SAMPLES), с версии на версию, с ОС на ОС (нужна всего лишь перекомпиляция). Но с 8.2 компилятор C для SP SQL не нужен, прям как в Oracle.
7 мар 06, 00:27    [2423707]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Victor Metelitsa
Цитаты про unicode относятся про случай unicode-строк в не-unicode базе. В unicode базе дела обстоят по-другому.
Честно говоря, вообще, не очень понятно, зачем такое деление на unicode/ не unicode базы? Казалось бы достаточно типа поля unicode/не unicode.
Кстати, как создается unicode база на DB2 - только заданием кодовой страницы при создании базы? А то на 7.2 для русского языка мне этого сделать так и не удалось.

Victor Metelitsa
Хранимые процедуры в DB2 8.2 совсем не обязательно писать на C, и они переносимы. Да SP и на C переносимы (см. SQLLIB\SAMPLES), с версии на версию, с ОС на ОС (нужна всего лишь перекомпиляция). Но с 8.2 компилятор C для SP SQL не нужен, прям как в Oracle.
Поверю вам про 8.2 на слово, поскольку я его увижу лишь через месяц.
Хотя по языку Oracle все равно впереди, а с mssql2005 они уже практически наравне

Victor Metelitsa
Уверен, что для генерации GUID где-нибудь в интернете найдётся готовый код.
Попробуйте найти, я уже пытался для Linux...
Может вам больше повезет. Еще раз повторю, в любом случае это будет геморойнее, чем встроенный тип.
Вообще, если сравнивать с MSSQL, то набор встроенных типов у MSSSQL несколько богаче (есть даже variant).

По настройке и администрированию мне DB2, в принципе, понравился. При желании, сервер многое может взять на себя и делает это хорошо.
В этом они схожи с MSSQL. Чего не скажешь про Оракл (наш админ даже с 10-кой прыгает с бубном).
7 мар 06, 01:11    [2423734]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
База юникодная, если при создании выбрана кодовая страница utf-8. Зачем ibm'еры наставили столько ограничений юникодным строкам в неюникодной базе, не имею понятия. Наверное, так им было проще.

Язык хранимых процедур DB2 слабже оракулиного в том, что нет пакетов и аналога переменных уровня пакетов, слабже поддержка так называемой "объектности", включая отсутствие массивов и коллекций. В MS SQL это есть? Что касается вариантного типа, это, мне кажется, против "философии" DB2.

Если для линюха нет готового кода генерации GUID, то, надо думать, это говорит о реальной потребности в GUID.
7 мар 06, 09:56    [2424138]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вот уж не согласен.
Victor Metelitsa
Язык хранимых процедур DB2 слабже оракулиного в том, что нет пакетов и аналога переменных уровня пакетов, слабже поддержка так называемой "объектности", включая отсутствие массивов и коллекций. В MS SQL это есть? Что касается вариантного типа, это, мне кажется, против "философии" DB2.

Если сервер поддерживает схемы по владельцам и локальные временные таблицы, то пакеты и массивы с коллекциями особо не сдались, так как все это есть частичная реализация определенных задач и у других серверов просто на эти же задачи другая реализация.

Victor Metelitsa
Если для линюха нет готового кода генерации GUID, то, надо думать, это говорит о реальной потребности в GUID.

Если есть глобальные инкременты или сиквенсы или нет репликаций, то я лично потребности в GUID вообще не ощущаю - наоборот, если его использовать в качестве PK, то мы получаем одни недостатки в виде увеличения обьема данных и индексов, невозможности сортировки по нему, так как значения выдаются неупорядоченно и еще кучу геммора. Лично для меня GUID хорош только для ввода уникального обозначения данных для разных систем, то есть при интеграции и передаче данных, но никак для хранения в качестве основного идентификатора и работы с ним (та же песня, что и с XML).
7 мар 06, 10:15    [2424219]     Ответить | Цитировать Сообщить модератору
 Re: Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах  [new]
Random_Goodman
Member [заблокирован]

Откуда:
Сообщений: 3708
Так, ребят, вот что я решил. Скачаю-ка я ДБ2 в пятницу и поставлю у себя. Если мне удастся за выходные нарисовать процедурку и номально подключить ее к ASP.NET 2.0, то вопросов нет. Если нет - возьму все-таки MS SQL, потому как солюшенов на все его баги пруд пруди в Инете, а DB2+ASP.NET - темная лошадка.

Есть еще в принципе, вариант взять SQL Server DE, там вроде ограничение на 25 подключений, и нарисовать под него ручками транзакционную библиотеку. Тогда в принципе тормозить все-таки будет, но не сразу. А там и вдно будет, может на полноценную версию раскручу.
7 мар 06, 10:25    [2424275]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить