MSSQL, Oracle, PostgreSQL. Что выбрать?

[Rishat]

Да, ещё с августа теребим ТП по поводу выхода на PostgreSQL, говорят проблемы, обещали сначала в конце сентября, потом вообще на неопределенный срок."Как будет, так скажем".

[smv]

Да, ещё с августа теребим ТП по поводу выхода на PostgreSQL, говорят проблемы, обещали сначала в конце сентября, потом вообще на неопределенный срок."Как будет, так скажем".

PostgreSQL - для небольшого кол-во пользователей
MSSQL - дополнительный функционал от Галактики под названием НАП-сервер
Оракл - нужен очень грамотный специалист по его сопровождению, да и особых плюсов я то же вижу в этой СУБД для Галактики в ее сегодняшнем виде)

[Aleksandr]

У PostgreSQL есть проблемы с быстродействием. Обещают передать в коммерческую эксплуатацию в конце декабря.
"... небольшое количество пользователей" это сколько?

[vasya_serega]

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

[smv]

У PostgreSQL есть проблемы с быстродействием. Обещают передать в коммерческую эксплуатацию в конце декабря.
"... небольшое количество пользователей" это сколько?

не видел как работает PostgreSQL с Галактикой
максимально до 50 пользователей ( не работающих одновременно)

[AlexMK]

Админить базу на Oracle - занятие еще то. ...

Если не секрет - расскажите в чем именно "ТО" заключается ?
И чем отличается от "ТОГО" при использовании любой другой СУБД ?

[vasya_serega]

Как админить другие СУБД не знаю, скажу честно. Поверхностную возню с MS-SQL или My-SQL себе в плюс записать не могу. Но вот что Oracle администировать, приходится читать кучу мануалов или рыть в книгах, что очень долго и затратно по времени, потому что интуитивно ничего не понятно, сказать могу. Может конечно и в других СУБД так же, если копнуть глубже, но здесь это занятие удовольствия мало приносит. От версии к версии ситуации немного улучшается, система часть функций берет на себя, дает осмысленные подсказки, как оптимизировать экземпляр, но всё равно, будь у меня выбор, не факт, что у нас Галактика крутилась бы на Oracle.

[Bandito_Gangsterito]

И MS SQL Server, и Oracle, естественно, гораздо более мощные СУБД по сравнению с Postgre SQL. Если бюджет организации сильно ограничен, количество пользователей невелико, то логично остановить свой выбор на Postgre SQL. С администрированием PostgreSQL проще разобраться. MS SQL Server и Oracle более мощные СУБД, более надежные, предоставляют гораздо больше возможностей по настройке и оптимизации производительности. Если стоит выбор между MS SQL Server и Oracle, то объективно сложно отдать предпочтение какому-нибуль продукту. Я, например, больше работал с Oracle. Из личного опыта хочу сказать, что это очень мощная и надежная СУБД. С MS SQL Server работать мне пришлось сравнительно недавно. На мой субъективный взгляд эти две СУБД сейчас примерно на одном уровне.

[AlexMK]

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

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

Баян, но, говорят при въезде в Париж на какой-то из магистралей висит плакат: "Если Вы ведете машину и одновременно ласкаете вашу попутчицу, знайте - и то и другое Вы делаете плохо!"

Чтение и "рытье" для штатного ДБА, является частью его служебных обязанностей.
Я более 30 лет работаю с ORACLE, начинал на версии 2.3.2 на PDP 11 и до сих пор читаю и "рою" ...

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

Но безусловно, выбор ORACLE должен быть обоснован практическими потребностями организации. Ведь не станете Вы нанимать 30-ти тонный Белаз чтобы привести песка на детскую площадку, но если у Вас в организации планируется работа сотен или тысяч рабочих мест одновременно и объемы данных измеряются десятками и сотнями терабайт, то Ваш выбор предопределен. И технической составляющей и программной и, кстати говоря, соответствующего персонала.

Другое дело, что руководство обычно, скрепя сердце, соглашается с техникой и софтом, а вот на персонал оно смотрит почти всегда с некоторой степенью упрощения - "а что там сложного ? и с какой радости брать спеца с бАААльшой зарплатой, если он непосредственно "с лопатой" не бегает, а что-то там всего-лишь администрирует".
Если оно (руководство) до правильных взглядов не созрело - выбирать ORACLE не следует. (это мое сугубо ИМХО)

Ну а администрировать ORACLE, как и "готовить" - нужно просто уметь и тогда все вполне себе несложно.

Для примера могу рассказать о сервер оракловом, под СантаКрузом на пентиуме 133 Мгц (очень давно было) который стоя в кладовке без монитора и клавиатуры, отработал 4 года без приложения к нему рук сотрудников организации (лишь удаленно я там логи и прочие трейсы подчищал раз в месяц). В конце концов контора сменила офис и сервер попросту забыла при переезде
Правда на нем не Галактика эксплуатировалась, а попроще системка , да и объемы данных были не очень большие.

[Friendlyman]

Коллеги, точно не PostgreSQL!

ПИР №180.7463 от 28.03.2013
Краткое описание: Ломает триггер J$ при докомпиляции таблицы на PostgreSQL
Текущее состояние: Не будет решаться по причине:
Обоснование: проект закрыт
Отправлено: 29.03.2013