Сейчас разрабатывается довольно крупный проект с точки зрения нагрузки и сложности БД.

Изначально было принято решение предельно придерживаться методологии написания запросов, при котором перенос с одной СУБД на другую обойдётся меньшей кровью.
Для унификации запросов используется набор интерфейсов к БД - обёртки для SELECT, UPDATE, WHERE, и тд...

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

Вопрос:

Интересуют именно истории проектов и опыт. Есть ли вообще смысл в думать о какой-то ещё БД, если выбрана для разработки, скажем, PostgreSQL?
И обратный - чем вы руководствуетесь, когда принимаете решение, поддерживать несколько БД?

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


Здесь дело не только в запросах. Если у проекта достаточно высоки требования к согласованности данных, то для разных платформ их, скорее всего, придется обеспечивать по разному. Попытка унификации этого процесса, фактически означает вынос на прикладное звено обеспечения согласованности данных, замена нативно-датабазных функций собственным велосипедом. Вплоть до самопального обеспечения изоляции транзакций. И именно это, с моей точки зрения, очень трудоемко и, как правило, получается менее эффективно чем то же самое нативными средствами.

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

Это сообщение отредактировал(а) Zloxa - 6.11.2013, 09:24

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

Как исключение из правил мне приходит в голову только приложения-утилиты для работы с БД. И то...

Любые кейвалсторы, не подразумевающие аналитики.
Любые системы, для которых временная(ну или перманентная) рассогласованность данных не критична.
Таких задач, в общем - не так уж и мало. :unkwn

Да, раз зашёл разговор про кейвалсторы.
Если основная база PostgreSQL, я стараюсь использовать тип таблиц memory.
В некоторых проектах я подключал Redis. Особых преимуществ при подключении ещё одного хранилища(в данном случае Redis) я не нашёл. И возникает недостаток в качестве появления ещё одного синтаксиса работы с данными.

Не могу просто обосновать применение каких-то отдельных средств для хранения этих самых "рассогласованных данных".

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

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

Это сообщение отредактировал(а) Zloxa - 5.11.2013, 17:24

на холивар просто нет времени сейчас

на счёт кейвалсторов вопрос действительно возникает часто, и решение принимается как бог на душу положит

По совокупности условий - ответ нет.
Достаточно лишь вменяемо отделить DBAL

Но вот над выбором конкретной БД стоит подумать хорошо и заранее

Хотелось бы узнать подробнее о том, что вы называете вменяемостью.

В данном случае запрос формируется полностью на SQL.
DBAL используется при подготовке запроса(связывание переменных, проверка соответствия типов), при исполнении и выборке данных(различные фетчи). То есть довольно единообразные функции.

Даже работу с JSON стараемся перенести на сторону БД,  насколько это возможно. Абстрактный слой лепить сюда даже не пытались.



В этом я убедился ещё раз, спасибо.

Чтобы ваши запросы не были раздерганы по сотням разных мест.
Сосредоточьте их все в моделях как минимум.