PostgreSQL 9.2

Ну а если старая СУБД не справляется с возросшей нагрузкой? Когда проект только создавали, не думали, что будет такая нагрузка. А вот она появилась. Все остальные компоненты справляются нормально, а СУБД — нет.

Ты разбиваешь мне сердце. 5 звёзд и такая охинея.

охинея

Что это?

Ну а вообще тут некоторые многозвёздные линукс только по рассказам знают.

Ну а вообще лучше ли в этом деле Postgres, чем My, не знаю, но, допустим, с sqlite вполне могут возникнуть такие проблемы.

Ну а вообще лучше ли в этом деле Postgres, чем My, не знаю, но, допустим, с sqlite вполне могут возникнуть такие проблемы.

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

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

Ну а я тут причём? Я это не говорю.

Добавлены типы данных для диапазонов значений.

теперь не надо вешать триггеры?

а на что их надо было раньше вешать?

с sqlite вполне могут возникнуть такие проблемы.

у нее появилась своя специфика?

php не нужен)

чушь какая-то -_-. Я бы сказал C#, Java, php - вот мейнстрим. 1С - да. У нас редко нужен человек чисто для БД, обычно БД + программирование. Т.е., если хотите нормально зарабатывать, умейте БД + программирование. Любую БД, любое программирование.. (в пределах разумного конечно).

при проектировании реально мастабируемой системы

А кто сказал, что система - «реально масштабируемая»? А если в системе масштабируемостью и не пахнет, а тормозом стала именно субд? Потратить ещё вагон человеко-баксо-часов, или «по-бырому» поменять базу? Понятно, что правильно - переписать. Но ведь часто надо «здесь и сейчас», а «потом будет потом».

Да-да, пхп становится все больше похож на руби с каждым пятилетием. Но реализации gem, rack, bundler у вас скорее всего не будет, только лишь пародии. Потому что пхп не станет руби, а будет лишь пародией. Кто-то встроил в руби gem, rdoc, тестирование. Позже это оформилось в rubygems.org, rubydoc.info, bundler. Собственно рубисту осталось только писать код. А вам осталось только подражать рубистам.

9/10 если mysql не справляется, то oracle/postgres/... не справятся так же. Не думаю что разница между этими БД столь существенна. Ну 10%, ну 20.. Если система уперлась в БД и ни оптимизация БД, ни апгрейд оборудования не помогли, то надо включать мозг.

Есть у кого опыт «переежания» с 8.4, поделитесь, проблемами.

9/10 если mysql не справляется, то oracle/postgres/... не справятся так же

не апеллируя к статистике, это зависит от... многих и многих факторов

А кто сказал, что система - «реально масштабируемая»?

Тогда нахрена там СУБД?

Ну а я тут причём? Я это не говорю.

Абсолютно непричем. Но надо же кого-то ненавидеть

В этой нищебродской БД есть, например, advisory lock's, чего в Оракле, насколько мне известно нету. При многопоточной обработке очередей незаменимая вещь!

Это если про функционал говорить =)

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

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

Джава на много порядков богаче и быстрее pl sql, зачем писать хранимки на чем-то другом

писать хранимки на объектно-ориентированной жаве просто глупо. если уж писать на жава то к базе ходят через ORM, потому как при процедурном подходе там вообще бред получаеться и одна конструкция PL/SQL заменяет десяток строк жава.

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

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

Наворотов и в db2 хватает.

они впечатлит разве, что программера mysql

В этой нищебродской БД есть, например, advisory lock's, чего в Оракле, насколько мне известно нету. При многопоточной обработке очередей незаменимая вещь!

Advanced Quene в оракле был еще в 90х и это полноценный механизм очередей, а не те заготовки, что начали появляться в постгре ...

В оракле есть рекомендательные блокировки? Где?

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

В Postgres еще есть PL/Perl, PL/Python, интерграция с С++, но часто pl/sql удобнее для маленьких простых процедур.

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

Зато есть параллельные транзакции, которые могут поменять одно и то же и придётся потом разбираться, что делать.

писать хранимки на объектно-ориентированной жаве просто глупо. если уж писать на жава то к базе ходят через ORM, потому как при процедурном подходе там вообще бред получаеться и одна конструкция PL/SQL заменяет десяток строк жава.

Лол. PL/SQL это монстр из 70-х, его даже сравнивать смешно с более-менее современным языком.

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

Блажен кто верует. Если база работает и важна, никто её трогать не будет без очень веских причин.

Маленькие простые можно и на db2-шном sql-е писать, какая разница, хоть на бейсике. Я так понимаю, речь идёт о тех странных людях, которые суют в базу огромную кучу логики и кода в надежде сэкономить на трансфере между приложением и базой. И тут pl/sql ужасен, по крайней мере в тех местах, где я имел счастье с ним сталкиваться.

PL/SQL не разрабатывался для сложной логики. Лишний трансфер между приложением и базой на самом деле очень неприятная штука (при разумных объемах данных), но PL/Perl будет выгодней Java для создания процедур внутри сервера бд со сложной логикой.

Кстати, какую лучше брать свеклу для борща: крупную или мелкую?

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

P.S Юноша, ты плохого обо мне мнения если думаешь , что я не знакома с ORM.

Пока на нём куча всего работает - ещё как нужен. ЯП нужен не тогда, когда у него кучка ярых поклонников, смакующих его синтаксический сахар и прочие навороты. А тогда, когда на нём работает много проектов. Которые приносят деньги своим хозяевам. PHP с этим отлично справляется. Мне нравится больше Ruby, но объективная реальность нам подсказывает, что нужен больше PHP. Будьте реалистом. И снимите уже ващи розовые очки, вы не девочка из изумрудного города;)

P.S Юноша, ты плохого обо мне мнения если думаешь , что я не знакома с ORM.

Девушка (?) на лоре действительно уже чуть менее чем все это школота. Но не все. И последним комментарием вы явно попали пальцем в ж-пу леопарту.

Но если честно, я не догоняю, как ORM помогает легко и непринужденно перескакивать с базы на базу? А триггеры? А разная специфика выполнения запросов? А права доступа? Где это в ORM?

В оракле есть рекомендательные блокировки? Где?

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

Зато есть параллельные транзакции, которые могут поменять одно и то же и придётся потом разбираться, что делать.

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

Лол. PL/SQL это монстр из 70-х, его даже сравнивать смешно с более-менее современным языком.

ну пока более эффективного языка для манипулирования данными не придумали. for (select) loop в любом другом языке потребует десяток строк. и pl/sql это середина 80х, а основные фишки появились уже в семерке, 90-е.

Блажен кто верует. Если база работает и важна, никто её трогать не будет без очень веских причин.

десупорт базы не веская причина :) ?

десупорт базы не веская причина :) ?

дорого оплаченной базы

90% проектов не используют триггеров , не забывай , что в самой популярной БД для веба (Mysql) триггеров еще недавно не было. Так вот ORM и существует не только для работы с БД в рамках объектной модели языка , но еще и служит цели облегчения миграции с одной базы данных к другой. А что касается специфики выполнения запросов , так это и задача ORM свести все к среднему арифметическому .

P.S я не умоляю достоинств работы с БД без ORM . Но в данном контексте мы говорили о работе с ORM

PL/SQL не разрабатывался для сложной логики. Лишний трансфер между приложением и базой на самом деле очень неприятная штука (при разумных объемах данных), но PL/Perl будет выгодней Java для создания процедур внутри сервера бд со сложной логикой.

мусье знает толк в извращениях. в крупных канторах обычно несколько страниц табу на конструкции pl/sql, типа перегрузки операторов, что бы те кто будут супортить систему могли оринтироваться в коде. представляю подобный документ для перла, который не читабелен by design :)

дорого оплаченной базы

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

Advisory locks - рекомендательные блокировки, я ошибаюсь?

Про Оракл не в курсе был, благодарю, что просветили =)

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

99% животных на Земле это насекомые.

90% проектов не используют триггеров , не забывай , что в самой популярной БД для веба (Mysql) триггеров еще недавно не было.

Если от бд требуются только «таблички» и вся логика работы с данными внутри клиента бд, то это не работа с бд. Это либо экстремальное программирование (проект за один и на один день), либо безграмотность проектировщика проекта. И это ниша mySQL.

представляю подобный документ для перла, который не читабелен by design :)

Идеальный документ состоит из двух пунктов, которые по-сути такие:

1. Правила наименования функций

2. Функция ничего не изменяет, кроме данных в таблицах, т.е. не изменяет переменные среды, не делает перегрузку операторов и пр.

PL/Perl нужен для создания сложных процедур обработки данных, простые процедуры нужно писать на PL/SQL.

Advisory locks - рекомендательные блокировки, я ошибаюсь?

почитал про Advisory locks - знатный изврат. они вообще не блокируют объекты БД, они ставяться на обстрактные цифры. типа заблокировать(1), т.е. если два программера не предупредят друг друга и начнут изобретать оракловый AQ на базе этих локов получат чудеса в продакшене.

PL/Perl нужен для создания сложных процедур обработки данных, простые процедуры нужно писать на PL/SQL.

ога, тут играем, тут не играем, а тут мы рыбу заворачивали. представляю те сачстливые лица разработчиков, которые обнаружили в базе, которую предстоит супортить, часть логики на перле, часть на pl/sql :)

ога, тут играем, тут не играем, а тут мы рыбу заворачивали. представляю те сачстливые лица разработчиков, которые обнаружили в базе, которую предстоит супортить, часть логики на перле, часть на pl/sql :)

И это нормально. Вас же не смущает, что одни библиотеки пишутся на C, а другие на С++? Так же и тут — ядро логики строго на PL/SQL, расширения на PL/Perl.

Ну с ним только в два захода - через advisory lock выбираем строки, дальше for update, но там тоже некоторые нюансы вроде были...

И это нормально. Вас же не смущает, что одни библиотеки пишутся на C, а другие на С++? Так же и тут — ядро логики строго на PL/SQL, расширения на PL/Perl.

лично я бы точно не пошел в кантору, где намешано несколько языков. повторюсь, люди в крупных проектах устанавливают табу на многие фичи PL/SQL ради читабельноти кода, а тут перл, славящийся своей write fast, read slow

Зато есть параллельные транзакции, которые могут поменять одно и то же и придётся потом разбираться, что делать.

Это где ж такое берется?

Вас же не смущает, что одни библиотеки пишутся на C, а другие на С++?

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

UPDATE tbl1 t1 SET fld1 = sq.fld1 FROM (тут_идет_большой_селект) sq WHERE t1.id=sq.id

А чем ораклийное не устраивает?

UPDATE tbl1 SET fld1=(SELECT fld2 FROM tbl2 where tbl1.id=tbl2.id)

А что толку с того «изучения», если нет реальных нагрузок? Как тебе на локалхосте разработать и внедрить нормальный план резервного копирования полутерабайтной базы?

с легкостью менять базу данных с postgresql на mysql и обратно

за это надо сжигать в топках локалхоста.

а в чем проблема ? пока ты не процесишь реальный бизнес, оракл позволяет инпратся бесплатно на любой редакции

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

В таком случае предлагаю выбросить ORM и переписать руками всю работу с БД. Откуда вообще пошла эта дурацкая мода совать ормы куда надо и не надо? Какого альтернативно одаренного озарила мысль работать с нагруженной базой через усредненную кривую прослойку?

Это не СУБД не справляется, а твой орм. Ну и до кучи архитектор БД.

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

набрать пять жава кодеров и сильного архитека к ним это один бюджет, а вот собрать pl/sql команду бюджет уже совсем другой. жава+орм не будет чемпионом, потребует больше железяк, но будет как-то работать и если проектировал нормальный архитек, систему будет возможно ее супортить другой командой. понятно что на pl/sql все будет более оптимально, но и бюджет уже другой, отсюда и мода на ОРМы.