Что выбрать - 2! Выбор базы данных: так ли нужна логика/процедуры внутри БД?

Зависит от приложения. Если масштаб интерпрайз, то шли все нафиг и пили все на pl/sql и sun oracle bd.

Если хелоуворлд, то какая вообще разница?

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

Я и говорю - все зависит от приложения. Как плотно ему надо контачить с базой? Если вообще вся инфа в базе и вся инфраструктура завязана вокруг этой инфы (постоянные селекты/апдейты) то можно попробовать писать и логику внутри бд, а на норм. языках только гуйню.

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

Ок, у меня весь контент в БД, система - смесь вики с товарным каталогом и социальной сетью. Видимо, постгрес и часть функций в БД.

Спасибо!

так ли нужна логика/процедуры внутри БД?

Если у тебя банк или финансовая организация или работа с баблом - то нужны. В остальных случаях нет.

Если ты задаёшь такие вопросы, то реализуй всё в приложении.

это реально ускоряет работу системы

если к месту - да, и очень серьезно

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

Единственный их смысл - это хитрожопые отчеты

Оказывается не только одмины локалхоста доставляют ... ДэБэ-одмины локалхост-ДэБэ - тожж жгут :-)

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

Хранимки это ад для поддержки и еще больший ад при масштабировании. И триггера вместе с ними. Лучше весь этот функционал выносить в аппсервер. Оп, реально ускоряет работу горизонтальная масштабируемость - когда тот же аппсервер можно разнести на 10 машин и все заработает в 10 (ну почти) раз быстрее. С хранимками ты этого не сделаешь - они все крутятся на сервере БД.

Ну вот смотри, у меня, например, некоторые объекты (например, карточка товара) состоят из таблицы с однозначными характеристиками, и множества множественных связей с другими таблицами. Разве не логично спрятать от приложения эти связи на стороне БД?

Просто у меня счас запущена OpenERP, и она тормозит (но, возможно, она тормозит из-за того, что на виндовсе).

Работы без работы с баблом не бывает.

Логично, но по сути неправильно. Вся нагрузка ложится на одну базу, а ее наоборот надо бы по максимуму разгрузить. И еще не факт что тут дело вообще в процедурах - возможно БД спроектирована так, что кроме как хранимками ее осмысленно читать практически невозможно.

Короче это комплексный вопрос, хранимки сами по себе не существуют в отрыве от всего остального.

Есть у кого опыт, это реально ускоряет работу системы, или не париться и всё делать в приложении?

Сильно зависит от количества подключений. Минусы реализации в приложении - придётся продумывать целостность (атомарность, коммутативность и прочее), но это делается один раз при проектировании. Остальное - плюсы.

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

С другой стороны я насмотрелся на реализации логики в БД. Всегда получается УГ, как ни старайся.

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

upd: оно кстати и выглядит как костыль.

Ну, оно и не может выглядеть иначе. Вопрос, насколько это быстрый и эффективный костыль.

Вопрос, насколько это быстрый и эффективный костыль.

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

upd: Но за всё нужно платить. Обычно памятью. В принципе логика в БД оправдана если сервер СУБД заведомо на порядки мощнее клиентов. Тогда да. Но это уже из разряда оптимизаций.

Работы без работы с баблом не бывает.

Я имею ввиду, банк или биржу или бабло которое ты хранишь у себя. Интернет магазин это не работа с баблом в твоей базе.

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

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

В большинстве случаев нужна.

Есть у кого опыт, это реально ускоряет работу системы

Что именно и почему ты собираешься ускорять?

или не париться и всё делать в приложении?

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

Из плюсов такого подхода:

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

-- язык работы с данными в триггерах, хранимках, вьюшках очень близок к sql;

-- возможность управлять транзакциями прямо внутри СУБД;

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

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

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

язык работы с данными в триггерах, хранимках, вьюшках очень близок к sql;

И представляет из себя процедурное говно, привет из 90-х.

возможность управлять транзакциями прямо внутри СУБД;

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

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

Да понятно, что если проектировать по взрослому, то надо разносить базы. А для отчетов по хорошему вообще специализированное olap хранилие использовать. Но мы же тут скорее про наколеночное поделие, а не про большую промышленную систему.

производительность системы упрется в хранимки - то фиг ты БД смасштабируешь

Ты всерьез считаешь что я этого не знаю? Впрочем у меня хранимки не тормозят.

И представляет из себя процедурное говно, привет из 90-х.

Сейчас почти весь мейнстрим из 90х. Если хочешь функциональщины, пиши хранимки на хаскеле.

А кто мешает управлять транзакциями из аппсервера?

Ниже тебе анонимус написал.

Мда... Пиши как умеешь: преждевременная оптимизация — зло. Как запустишься и увидишь проблемы — тестируй, тестируй и ещё раз тестируй разные варианты.

Сейчас почти весь мейнстрим из 90х.

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

Если хочешь функциональщины, пиши хранимки на хаскеле.

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

Ниже тебе анонимус написал.

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

фейсбук или вконтакт не использует нормальные БД - они занимаются пых-пых на стеройдах

«Газпром или РЖД не пользуются услугами банков — они занимаются бухгалтерией» — так примерно звучит.

Какое отношение MySQL, Cassandra или GlobalsDB имеют к «пых-пых-стероидам»?

Ну я не так выразился. Был опыт работы как пользователь с Oracle BI - после этого я понял, что большинство баз данных в web проектах на php+mysql - ничем не лучше использования bdb для тех же задач, а вот вся мощь БД - она где-то ещё, при правильном применении, а не select/insert.

И, кстати, да. За газпром не скажу, к нему привязано много фининститутов, а РЖД не занимается современной оптимизацией финансов.

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

Парни, что-то много эмоций в треде, поубавьте пыл =) Транзакции в БД лучше тем, что их не нужно реализовывать. Я не пытаюсь набросить, просто вы как-то однобоко описываете преимущества одного подхода и недостатки другого.

Транзакции в БД лучше тем, что их не нужно реализовывать.

Я уж и не помню, когда мне приходилось руками реализовывать транзакции в аппсервере. Все приличные фреймворки эту рутину автоматизируют, причем обычно гибче, чем хранимки, в которых даже лог ошибки нормально никуда не запишешь (потому что при ошибке все откатывается к известной матери, в том числе и записи в отладочны таблицы).

Ты же понимаешь, что это аргумент типа «зачем мне использовать сторонние реализации транзакций, когда у меня есть родные в СУБД». Я тут весь тред пытаюсь сказать, что плюсы и минусы есть у обоих подходов, а вы все в одну сторону склонить пытаетесь. Нравится тебе реализовывать логику только в приложении, а БД использовать как тупое хранилище данных - ну и делай так, архитекторы и проектировщики всего мира тебя поддержат. У меня могут быть причины опустить логику на уровень СУБД, я их уже озвучивать в треде, но это не случай ТС.

большинство баз данных в web проектах на php+mysql - ничем не лучше использования bdb для тех же задач

Неоптимальное использование баз никак не связано с их возможностями. MySQL тоже имеет достаточно мощные процедурные возможности. И, наоборот, все случаи использования Oracle, что я видел, касались или использования в роли простого табличного хранилища, или таких дебильных процедур, что их поддержка на уровне кода приложения намного проще и эффективнее. Как раз понемногу один такой проект сейчас разгребаю, перенося то, где использование Oracle не оправдано на MySQL.

а РЖД не занимается современной оптимизацией финансов.

Значит ли это, что РЖД не пользуется услугами банков?

В связи с санкциями у нас рассматривают возможность перехода на аналоги оракла. В тестах постгрес показал себя на 20% хуже оракла по производительности. Это результаты не только нашей компании, но и конкурентов. Сути тестов раскрыт не могу, т.к. не знаю, придется верить на слово анонимусу =) Так что плохая реализация приложения в оракле еще ни о чем не говорит, ни о его тормознутости, ни о его избыточности.

У Oracle божественный OLAP с дейтамайнингом, не обязывающий аналитика заранее проектировать кубы, а позволяющий их «пробовать». Как просто SQL сервер, естественно, Oracle в большинстве случаев избыточен. Постарайтесь таки не пугаться санкций там, где Оракл нужен.

Как просто SQL сервер, естественно, Oracle в большинстве случаев избыточен.

В том-то и дело, что не просто, у нас в нем даже бизнес-логика, но это легаси из 90х, которое постепенно переезжает на сервер приложения.

Постарайтесь таки не пугаться санкций там, где Оракл нужен.

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

Считаю хранимые процедуры одним из последних способов для оптимизации приложения, когда другие варианты уже не возможны и всё упирается в скорость обмена между БД и приложением. Если есть возможность реализовать обработку даннных на стороне приложения, ограничиваясь SQL, лучше делать так.