SQLExpress - за него денег вроде как не хотят.

GerrrЕсли 10 - тогда еще интереснее... остаются только ограничения на производительность, но это пока не попробуешь не поймешь разницы :)
Хорошо, а есть еще все же варианты которые express обходят по скорости, и при этом не сильно катастрофически уступают по переносимости с существующего MS SQL?
таких вариантов, увы, нет.
Кроме того, значительно дешевле будет занятся оптимизацией запросов, нежели перепиливанием системы на новый сервер.

РосгоснанораспилтрестGerrr, PostgreSQL - отличный вариант. Но процедуры - да, прийдется переписывать. Но зато у PostgreSQL есть плюс - можно выбрать язык, на котором писать хранимки: plpgsql, perl или python.
У экспресса есть один плюс - вообще ничего не надо переписывать :)

РосгоснанораспилтрестSiemargl, где-то обгоняет, где-то не обгоняет.

ТСу нужно бесплатное. MSSQL-то бесплатен, но он ограничен, и всё равно работает только на платной венде. А Постгрес работает везде.
ээээ... такой нескромный вопрос
а делфин, который упомянут в стартпосте - он тоже везде работает?

РосгоснанораспилтрестSergSuperпропущено...
с помощью CLR можно и на MS SQL на разных языках писать

А вот на pure C - низя. А в Постгри - можно. Если нужна какая-то специфичная функция, критичная по производительности - это крутъ.
в данном конкретном случае я сильно подозреваю что там нет "специфических функций, критичных по производительности".


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

Росгоснанораспилтрестlocky<Скиппед>

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

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

Ну, а вдруг понадобятся?
А что, у MSSQL есть такой вот открытый API для низкоуровневой реализации чего угодно ? Т.е. и агрегат напейсать можно, и тип, и операторы?..
Аггрегаты - можно, типы - можно
Операторы - нет.

Однако всегда возникает вопрос - а задлянафига это всё, простите, надо? :)

Dimitry SibiryakovРосгоснанораспилтрестТСу нужно бесплатное.
Об этом надо было задумываться до того, как он подсел на ни с чем не совместимый T-SQL.

"совместимых" их вообще всего ничего :)

РосгоснанораспилтрестlockyАггрегаты - можно, типы - можно
Операторы - нет.

Однако всегда возникает вопрос - а задлянафига это всё, простите, надо? :)

Ну, для Постгреса с помощью этого "задлянафига" много вкусностей написали (см. контриб, например). А если какой вкусности нет - можно написать самому/заказать написание на аутсорс, благо API там простой. Т.е. не зависишь на все 100% от желания левой пятки мейнтейнера.
Снова задаю вопрос - а задлянафига это надо, простите?

Росгоснанораспилтрестlocky, а задлянафига вообще MSSQL? Использовали б dBase какой-нибудь.
Эти вещи позволяют во многом облегчить разработку, поддержку и эксплуатацию БД.
MS SQL задлятого что он уже есть у ТС.

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

РосгоснанораспилтрестlockyMS SQL задлятого что он уже есть у ТС.

И он хочет с него на что-то перейти. Если проект небольшой, и какой-то супер-пупер-логики в хранимках нет - то перейти на PostgreSQL проще, чем на другие.
если проект небольшой - то надо переходить на экспресс.
Потому как переделок не требуется.

Росгоснанораспилтрестlocky, а если проект решит вырасти? А если ТСу не нужен дорогостоящий выньсервер? Если есть возможность быстро и относительно безболезненно перескочить на полноценную бесплатную СУБД - это надо делать.
Если нет - то переходить на ограниченный експресс, затягивать потуже ремень, и копить бабла на поепку воздухаMS(r) SQL(r) Server(r) 2008(r) R2(c) Enterprise(c) Edition(r) =)))

Вы знаете, если человеку потребуются возможности Sql Server 2008 R2 Enterprise Edition - у него найдутся на него деньги. И врядли подойдет постгре.


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

Росгоснанораспилтрестlocky, тут уже ТСу решать. Моя задача была сказать ему, что Постгрес - годная СУБД для перевода на неё проекта. Дальше - хай сам решает.
для небольших проектов - годно практически что угодно - мускул, экспресс, постгре, огнептиц, сайбейзы, дб пополам и прочая.
вопрос только в цене миграции.

Dimitry Sibiryakovlockyдля небольших проектов - годно практически что угодно

Собственно, этот список годен и для проектов любого размера. В умелых руках.

Вообще говоря - нет :)

Росгоснанораспилтрестlockyпропущено...

Вообще говоря - нет :)

Вообще говоря - да.
Вопрос только в цене. в т.ч. - "умелых рук" :)

Siemargl2. 150 процедур переписать и переучиться с T-SQL на PSQL это столько в деньгах? =)
зависит от.
я бы сказал, что ручное переписывание ясных и простых процедур - порядка 5-10 в день.
переучится с T на P - тут уж всё неопределено.....

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

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

Relic HunterGerrr,

У оракла есть мигратор с MSSQL. Можно ним попробовать в PostgreSQL. По pl/sql они должны быть очень похожи.

http://www.oracle.com/technetwork/database/migration/sqlserver-095136.html
я когда-то смотрел этот мигратор. Это было забавно :)