alex_v13 watson

PostgreSQL юзается тогда, когда возможностей MySQL уже не хватает, а на Orcale не хватает денег, но миграция на него в будущих планах, т.к. PG и OR обладают хорошим подобием функционала, даже на уровне синтаксиса хранимок до некоторой степени.
Хм. Ну, ИМХО это только один из вариантов. Более частый - нужна мощная фичастая СУБД за которую не нужно платить.

А по поводу отличий MySQL от PG - это в другой топик. Правда там че-то мало толковых завсегдаев этого подфорума.

Из вкусностей:
1. Лицензия. Хоть эскимосам продавайте :)
2. Мощнейшая система рулей.
3. Поддежка ХП на куче языков.
4. Отличная (ИМХО самая лучшая) поддержка стандарта SQL.
5. Версионность.
6. Функциональные и частичные индексы.
7. Отличная и удобная документация.
8. Возможность партиционирования данных.
9. Юниховая идеология (модули, контрибы, прикрычивания, прикомпилирование)
10. Огромное количество доп. проектов с помощью которых можно слепить почти все из уже готового.

Из невкусностей:
1. Требует на первых порах вдумчивого курения над документацией.
2. Иногда фичастость требует глубокого понимания (в смысле доки читать нужно) как оно устроено.
3. Нифига не масштабируется (сравните с Ораклом например).
4. Юниховая идеология (модули, контрибы, прикрычивания, прикомпилирование) - если с этим тяжко, мозгом шевелить тяжело и форточки форева, может наступить колапс головного мозга. Хотя лично у меня 90% решений - под винду и ничего.
5. Редко у кого это первая СУБД, как следствие попытки прийти в монастырь со своим уставом, и реализовать в нем то, что должно решаться другими способами. Из-за совместимости со стандартом до доки руки и глаза доходят поздно.
6. Огромное количество доп. проектов с помощью которых можно слепить почти все из уже готового. И это все в разных проектах.

MySQLCraft
ps. Мне просто интересно. Я сейчас пытаюсь юзать PostgreSQL и убеждаюсь что там как в Советском Союзе того нет, сего нет, а "возможности" работают до невозможности криво. Разделение таблиц, например, по SERIAL-первичному ключу... не работает.
Постгрес работает так как описано в доке. И работает ровно. И очень редко когда по другому Так что если у Вас что-то не работает и Вы можете указать на несостыковку доки и жизни - пишите, будем думать. Если же несостыковка в другом месте - то наверно это ж не к СУБД предъявы?

Если там чего-то нет есть несколько вариантов:
1. Это не нужно в реальной жизни
2. Это есть в ТУДУ и будет когда-нибудь сделано
3. Это облом всем делать (как вариант - подпункт п.1 )
4. 90% случаев - доку читаем невнимательно.
5. Реализация (честная) сопряжена с тяжелыми/непреодолимыми/гнусными трудностями и слабо формализована.
6. Вы первый кто до этого догадался.

ЗЫ А кидаться абстракными предьявами - ацтой. Только зарабатываете отрицательный авторитет на форуме. Есть конкретные вопросы - задавайте. Хотя лучше почитайте доку.

MySQLCraft Andrey Daeron[quot alex_v13] watson

Из вкусностей:
-------
готового. Это есть также и в MySQL
Ну я как бы рад за Мускуль. В свое время этого у него не было. Растет и это похвально. Решает свои задачи - ну и ладушки. Обсуждение и сравнение - не для этого форума - есть Сравнение СУБД.

4321к какому пункту из 6 вы отнесете наличие отсутствия довольно таки стандартного модификатора DESC в постгревом объявлении индекса?

или индексы более чем по одной колонке вещь для разработчика малонужная? или, для того чтобы слепить аналог такого индекса на коленке, инвертировать строку (и всякие прочия сравнимые типы) так же лехко, как число?
А можно поподробнее что за модификатор? Не сталкивался никогда.

ShadyAngelDESC.
Вот что пишет об этом дока по МусКЛ 5.0.:

http://dev.mysql.com/doc/refman/5.1/en/create-index.html
An index_col_name specification can end with ASC or DESC. These keywords are allowed for future extensions for specifying ascending or descending index value storage. Currently they are parsed but ignored; index values are always stored in ascending order.

Как в анекдоте "не понял".

А кому какая разница как оно храница? В PG есть только один/два реально работающих индекса - btree и тотже btree только вид сбоку GiST. Может быть для многоколоночных индексов это более актуально, хотя тоже ИМХО зависит от принципа хранения данных. Я не прав?

4321 Andrey Daeron
2. Это есть в ТУДУ и будет когда-нибудь сделано

к какому пункту из 6 вы отнесете наличие отсутствия довольно таки стандартного модификатора DESC в постгревом объявлении индекса?

или индексы более чем по одной колонке вещь для разработчика малонужная? или, для того чтобы слепить аналог такого индекса на коленке, инвертировать строку (и всякие прочия сравнимые типы) так же лехко, как число?
Ко 2-му. Есть в ТУДУ и даже будет след. релизе

Дошло нафиг такое нужно, действительно для запросов типа SELECT ... ORDER BY x ASC, y DESC, лучше что бы оно так и хранилось.