Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Биллинг на MSSQL? Однако... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 18:24 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
ASCRUS выйдет 10-ка, тогда и увидим, благо конец 1 квартала не за горами (если не обманут, как MS). А что Оракл 10 ещё не вышел? Или что вы имете ввиду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 18:31 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
пл скл ASCRUS выйдет 10-ка, тогда и увидим, благо конец 1 квартала не за горами (если не обманут, как MS). А что Оракл 10 ещё не вышел? Или что вы имете ввиду? Вышел. Давно при чем и достаточно неплохой, хотя народ еще предпочитает сидеть на 4-ом паке 9-ки (могу и ошибаться в цифрах, паки Оракла не считаю, своих хватает) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 18:35 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Oracle 10.1.0.4 уже считается вышедшим на качество продакшн. У нас вот стоит на боевом посту. Вышел сервис-пак к версии 10.2 - скоро и её начнут в продакшине применять. Если вы такие отчаянные ребята, что готовы использовать бесплатные версии БД, то напомню, что есть ещё и бесплатный Oracle XE (limits 1CPU, 4GB of data) Но я бы поостерёгся бесплатности. Да, при подсчёте стоимости учтите, что вторую БД (standby) надо тоже покупать. Ах да, у Оракла можно построить кластер, в котором падение одного из узлов происходит незаметно для пользователя ;). То есть сессия подхватывается выжившим узлом. Вам может понравиться эта фича ;) Вам бы окончательно определиться с тем, что вы хотите, выразить это на бумаге и отослать в Оракл, IBM и Microsoft - пусть они вам скажут, сколько это будет стоить. Я не раз слышал, что редко кто покупает по прейскуранту (особенно если знают, что рассматриваются предложения от конкурентов) Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 19:12 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать. Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 20:00 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Выбегалло Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать. Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре) А сколько стоит Informix, есть ли модная версия Express ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 20:07 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.Как недавно плотно занимавшийся ознакомлением DB2 скажу: DB2- база хорошая, но посмотрите для себя внимательно следующее: 1) Посмотрите как и чем вы с ней будете работать. Инструментария мало и он не удобен. 2) По сравнению с другими, плохая поддержка UNICODE. 3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными. 4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой. 5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 21:11 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Leonid3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.Вернее в MSSQL они настраиваемые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 21:20 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Leonid Leonid3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.Вернее в MSSQL они настраиваемые. в DB2 есть настраиваемые таблицы сортировки как раз для этого случая. Но об этом я знаю только теоретически, как на практике - не знаю. Вот ссылка на примере iSeries, где рассказывают про collating sequences. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 21:41 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
1024 при такой постановке лучше взять то что знаешь. В соседней ветке посмотри, про Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG) Не надо относиться к ним так уж серьёзно. Интерес в них в лишь том, что можно поковыряться лично и позадавать вопросы самому себе, почему так получилось и нельзя ли что-то ускорить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:35 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Leonid Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать.Как недавно плотно занимавшийся ознакомлением DB2 скажу: DB2- база хорошая, но посмотрите для себя внимательно следующее: 1) Посмотрите как и чем вы с ней будете работать. Инструментария мало и он не удобен. Ну, это вещь субъективная. 2) По сравнению с другими, плохая поддержка UNICODE. В чём? 4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой. В чём? 5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо. Я полагаю, это очень легко сделать, если приспичит (и вы дружите с C). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:44 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Выбегалло Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать. Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее Откуда вам такое известно? И это верно на любых конфигурациях и запросах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:50 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Anton Demidov Leonid Leonid3) В отличии от MSSQL VARCHAR-ы case и accent-зависимые. "Ёжики" и "ежики" в индексах будут разными.Вернее в MSSQL они настраиваемые. в DB2 есть настраиваемые таблицы сортировки как раз для этого случая. Но об этом я знаю только теоретически, как на практике - не знаю. Вот ссылка на примере iSeries, где рассказывают про collating sequences. Увы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:52 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaУвы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД. То есть ты хочешь сказать, что это фича AS/400 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 22:55 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
ASCRUS Выбегалло Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать. Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее, и если делать failover, то на второй машине можно выполнять запросы (в отличие от DB2, которая не позволяет никак использовать вторую машину в паре) А сколько стоит Informix, есть ли модная версия Express ? Express есть, но в экспрессе нет репликации. Сколько стоит - не знаю, как обычно, надо торговаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 23:06 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Anton Demidov Victor MetelitsaУвы, DB2 for Linux, Unix, & Windows, и DB2/400 - это совершенно разные СУБД. То есть ты хочешь сказать, что это фича AS/400 ? Да. Понятно, где эти таблицы лежат (SQLLIB\conv), и IBM предлагает их менять самим в некоторых случаях в качестве workaround'а на другие готовые (четыре штуки SQLLIB\conv\ms), но создать самим не позволяют, и готовых нечуствительных к регистру для русских нет. Что не означает, что проблема совсем уж неразрешима. Можно использовать generated-колонки (что, в свою очередь, в данном применении workaround к отсутствию индексов по выражениям). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 23:07 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Выбегалло Random_GoodmanЧе-то я склоняюсь к DB\2. Быстрая, надежная, бесплатная. а платная не так уж и дорого стоит, по сравнению с тем же Ораклом. Но надо подумать. Из DB2 и Informix я бы однозначно выбирал informix. на тех же ресурсах работает быстрее Откуда вам такое известно? И это верно на любых конфигурациях и запросах? называется "anecdotical evidence" - поскольку поучаствовать в TPC Информикс не пускают. От работников саппорта, которые раньше занимались informix_ом а теперь DB2. нет, не на любых запросах - обязательно найдется хоть один запрос, который на СУБД А выполняется дольше, чем на СУБД Б, при любом значении А и Б. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 23:11 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
По сообщению агентства ОБС, т.е. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 23:12 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Leonid2) По сравнению с другими, плохая поддержка 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 Leonid4) Написание хранимок по сравнению с MSSQL и Оракл - еще тот геморой.В чём?Для того чтобы написать хранимку под win мне пришлось поставить старый VS, поскольку от VS2005 Си-шный nmake не подходил. Это может и фигня, но фактически SQL-льные хранимки в DB2 это жестко-платформенно откомпилированные модули. Разве не так? В кросплатформенном Оракле нет необходимости такой компиляции процедур на PL/SQL (хотя она и возможна), а на T-SQL и подавно. И они будут переносимы с версии на версию и с сервера на сервер с минимальными телодвижениями. Victor Metelitsa Leonid5) Тип GUID не поддерживается и в ближайшее време небудет. Хотя далеко не всем надо. Я полагаю, это очень легко сделать, если приспичит (и вы дружите с C).Под win не сложно, под Linux немного сложнее. Я, например, не знаю точного алгоритма создания GUID. Попробуйте найти и создать, если хотите. В любом случае, это не будет так просто, как встроенный тип. Но опять же повторюсь, далеко не всем это надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2006, 23:38 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Цитаты про unicode относятся про случай unicode-строк в не-unicode базе. В unicode базе дела обстоят по-другому. Хранимые процедуры в DB2 8.2 совсем не обязательно писать на C, и они переносимы. Уверен, что для генерации GUID где-нибудь в интернете найдётся готовый код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 00:13 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Да SP и на C переносимы (см. SQLLIB\SAMPLES), с версии на версию, с ОС на ОС (нужна всего лишь перекомпиляция). Но с 8.2 компилятор C для SP SQL не нужен, прям как в Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 00:27 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
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-кой прыгает с бубном). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 01:11 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
База юникодная, если при создании выбрана кодовая страница utf-8. Зачем ibm'еры наставили столько ограничений юникодным строкам в неюникодной базе, не имею понятия. Наверное, так им было проще. Язык хранимых процедур DB2 слабже оракулиного в том, что нет пакетов и аналога переменных уровня пакетов, слабже поддержка так называемой "объектности", включая отсутствие массивов и коллекций. В MS SQL это есть? Что касается вариантного типа, это, мне кажется, против "философии" DB2. Если для линюха нет готового кода генерации GUID, то, надо думать, это говорит о реальной потребности в GUID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 09:56 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Вот уж не согласен. Victor MetelitsaЯзык хранимых процедур DB2 слабже оракулиного в том, что нет пакетов и аналога переменных уровня пакетов, слабже поддержка так называемой "объектности", включая отсутствие массивов и коллекций. В MS SQL это есть? Что касается вариантного типа, это, мне кажется, против "философии" DB2. Если сервер поддерживает схемы по владельцам и локальные временные таблицы, то пакеты и массивы с коллекциями особо не сдались, так как все это есть частичная реализация определенных задач и у других серверов просто на эти же задачи другая реализация. Victor MetelitsaЕсли для линюха нет готового кода генерации GUID, то, надо думать, это говорит о реальной потребности в GUID. Если есть глобальные инкременты или сиквенсы или нет репликаций, то я лично потребности в GUID вообще не ощущаю - наоборот, если его использовать в качестве PK, то мы получаем одни недостатки в виде увеличения обьема данных и индексов, невозможности сортировки по нему, так как значения выдаются неупорядоченно и еще кучу геммора. Лично для меня GUID хорош только для ввода уникального обозначения данных для разных систем, то есть при интеграции и передаче данных, но никак для хранения в качестве основного идентификатора и работы с ним (та же песня, что и с XML). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 10:15 |
|
||
|
Postgre vs DB/2 vs MS SQL 2005 на серьезных запросах
|
|||
|---|---|---|---|
|
#18+
Так, ребят, вот что я решил. Скачаю-ка я ДБ2 в пятницу и поставлю у себя. Если мне удастся за выходные нарисовать процедурку и номально подключить ее к ASP.NET 2.0, то вопросов нет. Если нет - возьму все-таки MS SQL, потому как солюшенов на все его баги пруд пруди в Инете, а DB2+ASP.NET - темная лошадка. Есть еще в принципе, вариант взять SQL Server DE, там вроде ограничение на 25 подключений, и нарисовать под него ручками транзакционную библиотеку. Тогда в принципе тормозить все-таки будет, но не сразу. А там и вдно будет, может на полноценную версию раскручу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2006, 10:25 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33585922&tid=1553631]: |
0ms |
get settings: |
7ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
97ms |
get tp. blocked users: |
2ms |
| others: | 223ms |
| total: | 410ms |

| 0 / 0 |
