Здравствуйте уважаемые!!! Есть такой вопросец: мне необходимо сделать выбор между следующими СУБД (задача учебная):
1. MS SQL Server 2005.
2. Oracle 10g.
3. Informix.
4. MySQL.
5. MS Access.
6. PostrgeSQL.
и в итоге выбрать SQL Server 2005. Всеми правдами-неправдами разобрался с Oracle 10g, Informix.

Начальные условия: платформа Windows, всего 18 таблиц, но записей в них максимально может быть порядка 200000 (макс. возможный размер БД 18 ГБ)... Скорость обработки запросов не имеет значения...

Помогите найти минусы ACCESS, MySQL и POSRGESQL  в сравнении с MS SQL Server 2005.

Заранее благодарю всех, кто попытается помочь..... 

 Записывай: 

=)))))))))) ЖЖОШЬ!!!! Но к сожалению, моё разработанное ПО должно работать на фирмах... поэтому выбор того или иного СУБД нужно обосновать... 

нет хранимых процедур, представлений, доменов

Добавлено через 25 секунд
помоему в мускуле тоже нет хранимок

Akella, есть там все в мускуле. В том числе и хранимые ф-ии/процедуры.

И насколько я с этими СУБД работал, то не выбрал бы MS SQL Server. Особенно синтаксис хранимок меня взбесил(хоть это и не касается функционала). А возможность выборки результатов нескольких первых начиная с определенного появилась только в 2005. До этого приходилось юзать 2 TOP'а с разным порядком сортировки.


IlyaDipl, так выбрать оптимальную, или же пропиарить MS SQL?

Это сообщение отредактировал(а) nerezus - 22.5.2008, 21:22

2 nerezus: вы правильно поняли... ИМЕННО ПРОПИАРИТЬ НАДО MS SQL Server.... 

ибо почитав про остальные БД я бы не заморачиваясь выбрал что-нить по-приличней и по-бесплатней... =))

учебная задача, говоришь ;)



только начиная с 5й версии ...

Добавлено через 1 минуту и 13 секунд

вот список фич MS SQL
вы главное не вспоминайте другие субд в докладе, бо почти всюду эти фичи есть ...

 А какие везде сейчас? Сейчас развивается 5ая и поддерживается 4.1(заплатки). Более ранние версии считать уже не существующими.

 А так же еще куча других )

нет... не то, чтобы пропиарить...  нада обкакать остальные СУБД... найти минусы... других...

минус их в том, что они такие хорошие ;).

oracle - слишком много фич, в итоге сильно навороченная бд - долго разбираться, много реурсов , для вашей задачи это слишком круто (дорого).
access - базы на 20 гиг не потянет, слишком слабо.

Postrge SQL , MySQL -  самое оно , для твоей задачи ..

кстате, а на чём будет реализовываться взаимодействие с бд?

Взаимодействие с БД уже реализовано... на вижуал студии... на шарпе... просто СУБД уже выбрано (MS SQL Server), если чесно, было выбрано преподом... и теперь нужно обьяснить выбор... 

1. с Аксесом я разобрался... там подключений <256, а у мя их штук 500 может одновременно быть... 

2. Оракл - дорогой... его тож откидываем (ибо задача не особо большая... да и предполагаемая (воображаемая) фирма стока отдавать не будет)... 

а вот с остальными СУБД напряг... я про них прочитал и понял, что на самом деле там тока одни плюсы... и выбирать нужно было либо Постр, либо Маскаль.... но уже поздняк метаться.... =((((((((

 Стоп. Тогда у тебя не такая задача. апиши, что по заданию ты использовал MS SQL, но лучшим выбором была бы {нужное вставить}.

Есть ряд задач, где MS SQL будет оптимальным вариантом, но, думаю, твоя задача явно не из них.

 За тебя выбрали. Вот и скажи, что это сделали за тебя, но по описанию подбери для себя лучшую.
Это же универ. «Студент должен не научиться, а за**аться» ©
Тем более что теоретич. часть ты сделаешь в виде сравнения.

Добавлено через 2 минуты и 37 секунд
 А что по поводу 500 соединений говорит железо? ))

 Есть бесплатные версии, ровно как и у MS SQL есть версия Express.

Зачот  

Модератор: поскольку нужен именно пиар, а не нормальное сравнение переношу в Религиозные войны.

P.S. IlyaDipl, ты блондинка?

Я уважаю мнения и отзывы других людей... нет, я не блондинка.... Нет, мне пиар не нужен... мне просто нужны минусы СУБД... совершенно любые... но я работал тока с Аксессом и Майкрософтовским Скулем... хотя много перечитал по поводу остальных СУБД... 

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

А почему тогда название одними заглавными?  

 Почему? Я сомневыюсь, что ты использовал какие-то особенности Ms SQL
Поэтому тебе изменить надо лишь строку соединения с базой наверняка(если ты не использовал всякие кривые классы для коннекта).

2LSD: А почему у Вас ник одними заглавными?? Вы тоже блондинкО??? =))))))) (вывод по Вашей же логике)....

Добавлено через 1 минуту и 43 секунды
Дело в том, что я использовал автоматически созданные элементы (т.е. коннект не прописывал, а работал с автоматически созданным Дата Сэтом)... =(( 

ну вот тебе и вывод: VS само создало код соединения с СУБД, что является облегчением работы для программиста.
Устраивает?

Добавлено через 31 секунду
При должной сноровке это предложение на пару страниц расписатьможно ) Студент же все-таки )

мда... впринципи неплохо.... и расписать можно... просто на предзащите меня препод спосил: "А почему вы исключили Postrege SQL???" - и это меня поставило в тупик... ибо к тому моменту я не знал, что такая СУБД вообще существует...

Это сообщение отредактировал(а) IlyaDipl - 23.5.2008, 16:33

IlyaDipl, если там сидят люди, которые задают резонные вопросы:

может, вместо того, чтоб придумывать недостатки, которые не являются недостатками, написать, что мол "так как имею опыт работы с МССКЛ, то время разработки и скорость отладки являлось единственно важным критерием выбора СУБД"? Тем более, что бесплатная(developer edition), хоть и довольно урезанная версия у mssql server есть...

 Потому что у него лицензия BSD, а известно, что под этой же лицензией существует система FreeBSD, порождение дьявола; мне дорога моя душа и я не хочу гореть в аду!

А если серьезно, то интерфейс между генерируемым VS кодом и отличными от MS SQL Server непрозрачен и потребовались бы дополнительные телодвижения.

Нет, не по моей логике, а по женской. Я не спрашивал почему СУБД набрано заглавными, это аббревиатура, их принято писать заглавными, так же как и мой ник. А вот МИНУСЫ аббревиатурой не является  

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

По сабжу:
PostrgeSQL - необходимость периодически выполнять vacuum
Access - как сервер БД работать может, но с большим напрягом, это больше файловая СУБД
MySQL - с хранимыми процедурами и триггерами напряг, они есть но пока не очень развиты (сам язык написания ХП хромает)
У всех вышеперечисленных СУБД крайне слабый оптимизатор запросов и средства тюнинга производительности (партишенинг, кластеры и т.д.).

С Oracle ситуация сложнее, это СУБД того же класса что SQL Server. Недостатки конечно есть, но незначительные. На всякий у Oracle плохо с ..., найдется свой а у SQL Server плохо с....

P.S. Выбрал бы Oracle можно было бы сказать, что это самая быстрая СУБД на свете 

Добавлено через 1 минуту и 21 секунду

Он же не свой сервер собирается писать, а использовать готовый 

 Конечно же нет. Так же она позволяет сделать с кодом практически все, что угодно. Самая лояльная лицензия по отношению к разработчику.

 Да даже если свой на основе существующего - то все равно не требовал бы. Это вам не GPL )

 До 7 версии включительно. В 8 автоматизировано.

 ХП с языком на бейсикоподобном уровне. Но впринципе чем бейсик не язык, чем язык не бейсик («Чем трупы не еда» © Мясокомбинат им. Путина №1)

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

Но всё равно, на сколько я понимаю, при обработке большого количества данных VAСUUM будет существеннно тормозить работу системы... Да?????

Это сообщение отредактировал(а) IlyaDipl - 23.5.2008, 19:29

А что про Firebird/Interbase забыли?

ну да.... впринципи... и об этой СУБД хотелось бы услышать мнения экспертов.... 

А в чем проблема?
Я вот второй раз вижу эту хрень, но разобраться труда не составило:

Очень хорошо, что мы в регилиозных войнах. Есть у меня следующее имхо.

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

Желаю приложиться чем-нибудь о что-нибудь, и честно сказать заказчику о причинах выбора.

 чо?   
он данные не обрабатывает. СОВСЕМ НИКАК не робрабатывает. Он чистит. И вообще уже не нужен в последних версиях.

    ухо горло нос сиська писька хвост. Я прочитал старинную мантру по изгнанию демона, уничтожающего орфографию   

В постгресе есть массивы. А еще там есть питон, и он живет прямо в хранимых процедурах   

нет, vacuum для очистки нужен... и даже если он делается автоматом, на это СУБД затрачивает время и ресурсы... эта плоха... =))))

IlyaDipl, у тебя есть бенчмарки, которые показывают, что это плохо?
А тебе не кажется, что оно может накапливать цели для вакуума, экономя m на запросе, где n количество запросов, а vacuum делается за v времени.
В итоге получаем, что vacuum ускоряет процесс при значении v < m*n   

Такой вариант не думал? )

если уж ты в рамках своей задачи разобрался с ораклом и информиксом, то про остальное в объяснениях можно просто скривить фэйс и сказать "тю".

В 8-ке не нужен вакум или он там выполняется автоматически? Дай ссылку где об этом можно почитать.

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

и получаем наши законные 57:43:12, до тех пор пока среди интервалов не окажется интервала более суток и пот тогда мы получим замечательное: 2 days 76:12:32. Мне вот просто интерестно они как вообще эти интервалы суммируют, по компонентно что ли.
Или например разная политика объеденения колонок в union, одна версия объединяет их по именам, другая по порядку следования, если совпадают типы иначе вообще каким-то непостижимым образом.
Или невозможность изменить поведение каскадов в foreign key, только удалить и создать заново. Со всеми прелестями создания индексов заново.
Хранимые процедуры можно писать на 10 различных языках, но основной PL/pgSQL неразвит.
Может быть конечно это дело не в постгресе, а я зажрался после Oracle.


Ну ладно, пока оставим это дело в покое. Но у меня было впечатление, что все таки не все там так гладко. 
А можно там писать хранимки на другом языке, например написать на Си скомпилить в dll и подключить как хранимку?

да. причем, если не ошибаюсь, UDF были уже задолго до 5 версии

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

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

Про это речи я не видел 


Так пусть так и напишет, а не придумывает отмазки.

Это скорее похоже на заплатку, чем на нормальное решение. Другие СУБД сами повторно используют табличное пространство, без всяких вакуумов в часы наименьшей нагрузки.

Не знаю точно, это минус самого PostgreSQL или кривая реализация JDBC драйвера: нельзя сделать большую выборку (~100 000 строк), вылетает OutOfMemoryError. Судя по всему, он пытается сразу весь курсор загнать в память. В том же Oracle курсор находился на сервере, и по мере скролинга подгружался на клиента.

выгружал из Postgre большие выборки (несколько сотен тыс. строк) на клиент... правда работал через Зеос. Нормально, хоть и жрало память.
Постранично - это конечно хорошо, но что делать, когда нужно дофига данных в кубе обработать?  

Если мне не изменяет склероз, в статемент в postgres jdbc можно указать размер буфера для считывания записей из курсора. Что то типа

statemet.setFetchSize(100); чтобы считывать по 100 записей из курсора. Ну и соответственно resultset надо при этом делать типа ResultSet.TYPE_FORWARD_ONLY