Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Конечно интересно, обязательно продолжайте!
Да, да, да и ещё раз Да. Верным путём.
Тэги тока поправьте, могут не найти.
Тэги тока поправьте, могут не найти.
Форматирование кода у Вас (а именно отступы) — вырви глаз :)
Кстати, объясните подробнее про помещение операторов SQL в отдельные процедуры и функции. Какие это дает преимущества?
Кстати, объясните подробнее про помещение операторов SQL в отдельные процедуры и функции. Какие это дает преимущества?
>> Кстати, объясните подробнее про помещение операторов SQL в отдельные процедуры и функции. Какие это дает преимущества?
Первое и очевидное, это то что достаточно часто операторы повторяются в коде.
А второе и самое главное, что при изменении требований к тому что возвращает оператор можно менять процедуры и функции не перекомпилируя другие объекты (они не становятся инвалидными). То есть можно прямо на работающей системе заменить функцию и при следующем вызове она будет использована (естественно стоит ее протестить и не забыть приписать CREATE OR REPLACE).
Первое и очевидное, это то что достаточно часто операторы повторяются в коде.
А второе и самое главное, что при изменении требований к тому что возвращает оператор можно менять процедуры и функции не перекомпилируя другие объекты (они не становятся инвалидными). То есть можно прямо на работающей системе заменить функцию и при следующем вызове она будет использована (естественно стоит ее протестить и не забыть приписать CREATE OR REPLACE).
По-моему в ваших словах есть некоторое противоречие.
С одной стороны известно что переключение контеста PLSQL / SQL дает определенный оверхед и вы справедливо рекомендуете этого избегать.
С другой стороны вы рекомендуете оборачивать SQL операторы в PLSQL.
С одной стороны известно что переключение контеста PLSQL / SQL дает определенный оверхед и вы справедливо рекомендуете этого избегать.
С другой стороны вы рекомендуете оборачивать SQL операторы в PLSQL.
Здесь нет никакого противоречия. Само по себе переключение контекста — это очень быстрая и ненапряжная операция. По сравнению с выполнением sql-оператора — копейки. Т.е. выполнять для sql-запроса одно дополнительное переключение контекста ничего не стоит.
Проблемой становится когда переключение контекста выполняется для каждого фетча в запросе ( как в самом первом куске кода). Т.е. если запрос возвращает 100 млн строк, то будет 200 млн. переключений контекста ( туда-сюда), а это уже совсем другое дело.
Проблемой становится когда переключение контекста выполняется для каждого фетча в запросе ( как в самом первом куске кода). Т.е. если запрос возвращает 100 млн строк, то будет 200 млн. переключений контекста ( туда-сюда), а это уже совсем другое дело.
Я думаю, что у автора не так отформатировано. Он-же какой-то тулзой пользовался, там написано.
>>помещение операторов SQL в отдельные процедуры и функции. Какие это дает преимущества?
Действительно интересный вопрос.
Мне доводилось над этим задумываться, когда я видел, как эту практику применяет и сам Oracle corp в некоторых своих решениях. Для каждого модуля они оформляют пакетик, в который выносят все SQLчики. Причем не сказал бы, что эти пакетики действительно повторно используется. Если бы их готовили как API для повторного использования, наверное следовало бы резать не по модулям, а по сущностям. API для работы с товарами, API для работы со складами. Так нет же. Они нарезают их по модулям. Делают пакет для формы ввода накладной, пакет для батча расчета потребности. Оба пакета могут содержать совершенно одинаковые DML, при этом в обоих пакетах нет не реализовано ни грамма логики.
Однако при такой организации оказывается достаточно удобно выявлять зависимости, проводить обратный инжиниринг. Уточнение схемы данных приводит к ревалидации и повредившиеся модули видно сразу, а не в процессе их исполнения, сразу же их можно и подправить, без пересборки приложения. Опять же, самый простой способ стабилизировать план запроса — переписать его, захинтовать. Но ели руководствоваться именно этими тезисами, впору усомниться в целесообразности выноса логики на приложение.
Действительно интересный вопрос.
Мне доводилось над этим задумываться, когда я видел, как эту практику применяет и сам Oracle corp в некоторых своих решениях. Для каждого модуля они оформляют пакетик, в который выносят все SQLчики. Причем не сказал бы, что эти пакетики действительно повторно используется. Если бы их готовили как API для повторного использования, наверное следовало бы резать не по модулям, а по сущностям. API для работы с товарами, API для работы со складами. Так нет же. Они нарезают их по модулям. Делают пакет для формы ввода накладной, пакет для батча расчета потребности. Оба пакета могут содержать совершенно одинаковые DML, при этом в обоих пакетах нет не реализовано ни грамма логики.
Однако при такой организации оказывается достаточно удобно выявлять зависимости, проводить обратный инжиниринг. Уточнение схемы данных приводит к ревалидации и повредившиеся модули видно сразу, а не в процессе их исполнения, сразу же их можно и подправить, без пересборки приложения. Опять же, самый простой способ стабилизировать план запроса — переписать его, захинтовать. Но ели руководствоваться именно этими тезисами, впору усомниться в целесообразности выноса логики на приложение.
Было дело, я сидел на Oracle и использование PLSQL давало офигенное преимущество. Теперь там где я работаю Teradata. И хватает просто написать правильно SQL, ну и чтобы индексы были на таблицах. Милиарды строк. Вопрос — почему Оракл так не может? Зачем так париться с отдельным языком?
PLSQL — дает возможность использовать процедурное программирование на стороне СУБД.
Соответственно PLSQL можно применять там где нельзя обойтись одним SQL, например: прочитать файл с сервера и загрузить его в таблицу, выполнить HTTP запрос, передав данные из БД и т.п. Бизнес логика иногда выносится на уровень СУБД — SQL тут не хватит.
Соответственно PLSQL можно применять там где нельзя обойтись одним SQL, например: прочитать файл с сервера и загрузить его в таблицу, выполнить HTTP запрос, передав данные из БД и т.п. Бизнес логика иногда выносится на уровень СУБД — SQL тут не хватит.
Вот таким деятелям, которые выносят бизнес-логику на уровень СУБД надо оторвать руки и засунуть в место, откуда они у них и должны произрастать. Блин, 21 век на дворе, все эти танцы с бубном вокруг СУБД уже давно пора заканчивать.
А можно как-то аргументировать эту позицию?
Тут не может быть 2х мнений. Если писать бизнес-логику на языках общего назначения, то поддерживать ее гораздно проще.
Понимаете, компилируемые языки, юнит-тесты, простые решения, отсутствие возможности что-то поправить на production сервере, все это значительно сокращает количество ошибок и располагает писать надежный код.
И, о ужас, вы сможете отказаться от использования Oracle, потому что не будете завязаны на конкретную СУБД.
Я даже позволю себе лирическое отступление.
Когда-то давно, ну, лет может 5-8 назад не было такого количества разных решений для работы с данными, никто не знал ни про какие map/reduce и nosql решения.
Зато был Oracle, который представлялся этакой серебрянной пулей и волшебно решал все проблемы с производительностью, стоил он, да и стоит сейчас тоже «волшебно».
Соотвественно была построена целая индустрия людей, которые знали только Oracle и гребли немеряно денжищ на этом.
Сила бренда по-прежнему велика, но зачем писать новые проекты под Oracle?
К сожалению, есть много организаций, которые рефлексивны по сути, например, банки, гос. структуры, корпорации-монстры и, единожды подсев, они
уже плотно сидят на этой Oracle игле.
Сейчас Вы можете написать приложение под MySql, PostgreSql, даже NoSql и оно будет не менее надежным и производительным, это почерпнуто из опыта.
Понимаете, компилируемые языки, юнит-тесты, простые решения, отсутствие возможности что-то поправить на production сервере, все это значительно сокращает количество ошибок и располагает писать надежный код.
И, о ужас, вы сможете отказаться от использования Oracle, потому что не будете завязаны на конкретную СУБД.
Я даже позволю себе лирическое отступление.
Когда-то давно, ну, лет может 5-8 назад не было такого количества разных решений для работы с данными, никто не знал ни про какие map/reduce и nosql решения.
Зато был Oracle, который представлялся этакой серебрянной пулей и волшебно решал все проблемы с производительностью, стоил он, да и стоит сейчас тоже «волшебно».
Соотвественно была построена целая индустрия людей, которые знали только Oracle и гребли немеряно денжищ на этом.
Сила бренда по-прежнему велика, но зачем писать новые проекты под Oracle?
К сожалению, есть много организаций, которые рефлексивны по сути, например, банки, гос. структуры, корпорации-монстры и, единожды подсев, они
уже плотно сидят на этой Oracle игле.
Сейчас Вы можете написать приложение под MySql, PostgreSql, даже NoSql и оно будет не менее надежным и производительным, это почерпнуто из опыта.
А vожете привести, пожалуйста, пример самой сложной в вашей жизни бизнес-логики?
Уж поверьте, «корпорации-монстры», перед тем, как «сесть на иглу», сотни раз просчитают, в частности стоимости других решений. И как раз, в «серьезном бизнесе» решения от Oracle очень тесно идут там где надо «рука об руку» и с OpenSource-решениями, и с решениями сторонних фирм, и с собственными разработками.
Уж поверьте, «корпорации-монстры», перед тем, как «сесть на иглу», сотни раз просчитают, в частности стоимости других решений. И как раз, в «серьезном бизнесе» решения от Oracle очень тесно идут там где надо «рука об руку» и с OpenSource-решениями, и с решениями сторонних фирм, и с собственными разработками.
Тут не в игле дело, а партнерских отношениях мега корпораций. Как примеры сложной бизнес логики реализованной на стороне СУБД это Oracle FlexCube (абс) и TiA (страхование).
Угу, сотни раз просчитывают, и, например, выбирают упомянутый выше ClearCase. Автор статьи пишет, что у них от него отказались, но я знаю корпорации-монстры, где используется только CC. Его критиковать проще, чем Oracle, так как в отличие от Oracle я пользовался ClearCase и в нем нет абсолютно ничего стоящего. Древний хлам, ужасно неудобный, по возможностям где-то на уровне CVS, по удобству на порядок хуже CVS, стоит немерянное количество зеленых бумажек. Не надо идеализировать корпорации, там нередко принимаются неоптимальные решения в стиле «За выбор Oracle еще никого не увольняли».
Давайте не будем о «серьезном бизнесе», это не аргумент. Мы разработчики, а не маркетологи, давайте рассуждать о технологических решениях. Я не очень понимаю, почему вы пишите о сложной логике. Я написал, что логика не должна быть на уровне СУБД, при чем здесь сложность?
За примером сложной логики и высоких нагрузок без Oracle, пожалуйста — Google, Discuss, их много. В моем опыте — покер Ongame Network.
За примером сложной логики и высоких нагрузок без Oracle, пожалуйста — Google, Discuss, их много. В моем опыте — покер Ongame Network.
>>Сила бренда по-прежнему велика
Да, есть такой момент. Был (и есть) у нас отличный продукт. Работает на Firebird. Для решаемых продуктом задач эта СУБД подходит идеально. Но, «сверху» пришло распоряжение портировать на MSSQL а потом и на Oracle. В маркетинговых целях. Т.к. «серьезные клиенты» воротят нос от б-го мерзкого опенсорсного Firebird'а.
Да, есть такой момент. Был (и есть) у нас отличный продукт. Работает на Firebird. Для решаемых продуктом задач эта СУБД подходит идеально. Но, «сверху» пришло распоряжение портировать на MSSQL а потом и на Oracle. В маркетинговых целях. Т.к. «серьезные клиенты» воротят нос от б-го мерзкого опенсорсного Firebird'а.
Ох. невозможно написать универсальное приложение, которое одинаково эффективно будет работать на всех СУБД. Лучшие умы Вселенной пытались, (не я, не, я идиод), но не выйдет. Везде есть свои особенности, я на двух базах нахлебался уже (Oracle ft. MSSQL)
А вообще, с возрастом проходит желание делать такие жесткие и однозначные выводы.
«Понимаете, компилируемые языки, юнит-тесты, простые решения, отсутствие возможности что-то поправить на production сервере, все это значительно сокращает количество ошибок и располагает писать надежный код.»
Fokken fok! PL/SQL компилируемый язык, с мощной возможность отладки.
А вообще, с возрастом проходит желание делать такие жесткие и однозначные выводы.
«Понимаете, компилируемые языки, юнит-тесты, простые решения, отсутствие возможности что-то поправить на production сервере, все это значительно сокращает количество ошибок и располагает писать надежный код.»
Fokken fok! PL/SQL компилируемый язык, с мощной возможность отладки.
«Невозможно написать универсальное приложение, которое одинаково эффективно будет работать на всех СУБД»Можете аргументировать? Приведите мне пример такого приложения и мы вместе разберемся, что там невозможно.
С возрастом приходит желание разбираться в сути вещей, а не сливать карму.
1) связанные переменные. Они во всех базах в запросах указываются по-разному. Разумеется, можно препарсер заделать, как у нас, но это так себе идея.
2) набор функций в БД, например в Oracle очень хорошо сделаны аналитические функции, а в MSSQL гораздо неприятнее с этим. То есть лично мне приходится так писать запросы, чтобы они работали одинаково в обоих базах. Соответственно, они менее эффективно работают в обоих базах. (Можно я не буду приводить примеры?)
3) Запросы можно составлять, с учетом конкретной архитектуры, например, если я знаю, что на сервере есть Parallel Query Option, то я и запрос напишу соответственно этому.
4) identity vs sequences — головная боль, в MSSQL есть ограничение на отключение identity в одной сессии и одновременно.
Сливают карму (по себе сужу), когда я делаю резкие выражения, типа я д'Артаньян, а остальные — не д'Артаньяны, а за что Вам слили, я не в курсе.
2) набор функций в БД, например в Oracle очень хорошо сделаны аналитические функции, а в MSSQL гораздо неприятнее с этим. То есть лично мне приходится так писать запросы, чтобы они работали одинаково в обоих базах. Соответственно, они менее эффективно работают в обоих базах. (Можно я не буду приводить примеры?)
3) Запросы можно составлять, с учетом конкретной архитектуры, например, если я знаю, что на сервере есть Parallel Query Option, то я и запрос напишу соответственно этому.
4) identity vs sequences — головная боль, в MSSQL есть ограничение на отключение identity в одной сессии и одновременно.
Сливают карму (по себе сужу), когда я делаю резкие выражения, типа я д'Артаньян, а остальные — не д'Артаньяны, а за что Вам слили, я не в курсе.
Хорошо, давайте сразу оговоримся, что мы хотим показать, что все это можно и не сложно сделать без Oracle.
Потому как обсуждать, что и как сделать проще и элегатнее нет смысла, т.к. человеку проще работать с тем, с чем он умеет работать, согласны?
Пойдем по пунктам:
1. Это смотря с чем сравнивать. Если у нас NoSql решение, то нам план запроса по барабану, нам только данные получить.
Если другие базы, то почему не hibernate или аналоги.
2. Аналитические функции бывают разные и вряд ли вы их все используете
Сумму можно сделать через счетчик, аналогично средние.
3. Map/reduce
4. Если абстрагироваться, то Вам просто нужен сервис, который выдает последовательно возрастающие числа, это такая проблема?
Потому как обсуждать, что и как сделать проще и элегатнее нет смысла, т.к. человеку проще работать с тем, с чем он умеет работать, согласны?
Пойдем по пунктам:
1. Это смотря с чем сравнивать. Если у нас NoSql решение, то нам план запроса по барабану, нам только данные получить.
Если другие базы, то почему не hibernate или аналоги.
2. Аналитические функции бывают разные и вряд ли вы их все используете
Сумму можно сделать через счетчик, аналогично средние.
3. Map/reduce
4. Если абстрагироваться, то Вам просто нужен сервис, который выдает последовательно возрастающие числа, это такая проблема?
Знаешь, я настолько олдфаг и слоупок, что для меня NoSql, это Adabas, в нем не было SQL, поэтому я просто не понимаю, о чем ты пишешь тут. Извини конечно.
2. Ну, FIRST_VALUE, LEAD, LAG — вот их очень часто. Специфика работы такая
4. В многопользовательской среде, это действительно проблема. Но в общем,
зависит от дизайна базы.
Вообще кажется до меня дошло, что такое NoSQL в вашем понимании.
Ну может быть, конечно, но отказоустойвость, масштабируемость у Oracle очень на высоте. Не знаю, я конечно мхом не порос еще, но я не видел (никто не показывал) какого-то NoSQL, который был бы достойной заменой RDBMS.
2. Ну, FIRST_VALUE, LEAD, LAG — вот их очень часто. Специфика работы такая
4. В многопользовательской среде, это действительно проблема. Но в общем,
зависит от дизайна базы.
Вообще кажется до меня дошло, что такое NoSQL в вашем понимании.
Ну может быть, конечно, но отказоустойвость, масштабируемость у Oracle очень на высоте. Не знаю, я конечно мхом не порос еще, но я не видел (никто не показывал) какого-то NoSQL, который был бы достойной заменой RDBMS.
Да, понимаю все, прикипаешь душой к одной технологии, которую знаешь. У меня так было, когда переходил с .net на Java.
Ну, вот, если разобраться.
2. FIRST_VALUE — первое значение в отсортированном списке, значит надо где-то хранить этот список и добавлять в него элементы
LAG и LEAD — отсортированный связанный список, никакой магии
Oracle внутри себя скорее всего строит эти структуры данных и работает с ними.
4. ну, в общем, решаемый вопрос.
Насчет масштабируемости Оракла не буду врать, не в курсе, видел его в продакшене только на мощных сановских серверах.
Я не против Оракла, просто мне думается, что большинство решений делать на нем проекты принимается под влиянием бренда или откатов, без всякого технического обоснования.
Ну, вот, если разобраться.
2. FIRST_VALUE — первое значение в отсортированном списке, значит надо где-то хранить этот список и добавлять в него элементы
LAG и LEAD — отсортированный связанный список, никакой магии
Oracle внутри себя скорее всего строит эти структуры данных и работает с ними.
4. ну, в общем, решаемый вопрос.
Насчет масштабируемости Оракла не буду врать, не в курсе, видел его в продакшене только на мощных сановских серверах.
Я не против Оракла, просто мне думается, что большинство решений делать на нем проекты принимается под влиянием бренда или откатов, без всякого технического обоснования.
А как насчет масштабируемости?
Интересно, что проще: запилить Oracle RAC или распараллелить «бизнес-логику на языках общего назначения»?
Интересно, что проще: запилить Oracle RAC или распараллелить «бизнес-логику на языках общего назначения»?
Верно и другое: нам уже несколько раз приходилось менять промежуточный слой: Forms / JSP / .NET / GWT, а база всё та же, т.к. вся логика в ней. И переходы были практически безболезненны.
Fafnir, не надо насчет «танцев с бубном». Если бы вы сами действительно достаточно «натанцевались с бубном в 21 и в 20 веках», вам было бы хорошо известно, что в достаточно более-менее серьезных проектах обычно существует очень много как горизонтальных так и вертикальных слоев бизнес-логики.
Да и общий обьем этой бизнес-логики такой, что не уместится сразу в голове у одного программиста. Много вы знаете программистов, которые одновременно бы являлись и высококлассными администраторами БД, и обладали бы знаниями бухучета на уровне хорошего аудитора, и понимали бы движения средств на уровне финдиректора фирмы, и отлично знани бы организационное взаимодействие между подразделениями фирмы, и владели бы всей информацией по логистическому движению, и знали бы о различных «тонкостях ведения бизнеса», владели бы отчетность и документооборотом, и при этом не забывая как писать высококлассный, надежный код, и более того, при этом держа в уме нехилую структуру БД и владея техниками оптимизации?
Я уверяю Вас, даже обладая интелектом Эйнштейна Вы сядете в лужу, пытаясь запихнуть всю бизнес-логику внутрь одного монстробразного неповоротливого приложения. А если и попытаетесь, то все равно у вас ничего не выйдет, потому что «O, Surprise», зачастую сами части этой бизнес-логики могут быть так разнесены даже географически и по часовым поясам и даже (не поверите… законодательно, то есть у вас будут реально разные части бизнес-логики, работающие по разному отражая требования разного законодательства), что Вам наверное даже это трудно будет представить!
Ну-ка? А теперь скажите, о чем думать программисту, о том, что на разных филиалах налоги считаются по разному алгоритму или о том на какой таблице какой индекс и какую одну таблицу с десятками миллионов записей как правильно сджойнить с другой таблицей с миллионами записей так чтобы сразу не парализовать работу?
Но это еще не все! А теперь, давайте взглянем на то, что над крупным проектом работаете не вы один а десятки других программистов и на логику БД завязаны сотни тысяч строк кода. Я умышленно сказал на логику БД а не на структуру БД.
Потому что если бы весь этот код был завязан на структуру БД, то у вас бы просто исчезла такая возможность что-то менять в структуре БД. А любой сбой в этих сотнях тысяч строк кода стоит миллионы денег, не забываем об этом, поэтому нельзя ничего из этого кода выводить из работоспособного состояния.
Поэтому выведение разумной части бизнес-логики на уровень СУБД, это далеко не прихоть, а суровая необходимость.
А в некоторых случаях единственно реально-доступная возможность, особенно, когда специально выделенный DBA занимается оптимизацией выполнения запросов, огранизацией хранения, резервирования, измением структуры, отказоустойчивостью БД, не вдаваясь в бизнес-логику, в которой он все равно нифига не поймет, в силу некомпетенции и в силу того, что он не смог бы ее окинуть взглядом. А созданием например, рабочего места для финдиректора, занимается программист, знающий что такое налоги, счета, договора и прочие вещи, в которые никогда не будет лезть DBA. А DBA может легко изменить структуру БД, например, по просьбе другого программиста, занимающегося, к примеру внутренней логистикой, не поломав при этом интерфейс БД.
Поэтому, пожалуйста, не делайте поспешных заявлений по поводу тех вещей в которых мало разбираетесь.
Да и общий обьем этой бизнес-логики такой, что не уместится сразу в голове у одного программиста. Много вы знаете программистов, которые одновременно бы являлись и высококлассными администраторами БД, и обладали бы знаниями бухучета на уровне хорошего аудитора, и понимали бы движения средств на уровне финдиректора фирмы, и отлично знани бы организационное взаимодействие между подразделениями фирмы, и владели бы всей информацией по логистическому движению, и знали бы о различных «тонкостях ведения бизнеса», владели бы отчетность и документооборотом, и при этом не забывая как писать высококлассный, надежный код, и более того, при этом держа в уме нехилую структуру БД и владея техниками оптимизации?
Я уверяю Вас, даже обладая интелектом Эйнштейна Вы сядете в лужу, пытаясь запихнуть всю бизнес-логику внутрь одного монстробразного неповоротливого приложения. А если и попытаетесь, то все равно у вас ничего не выйдет, потому что «O, Surprise», зачастую сами части этой бизнес-логики могут быть так разнесены даже географически и по часовым поясам и даже (не поверите… законодательно, то есть у вас будут реально разные части бизнес-логики, работающие по разному отражая требования разного законодательства), что Вам наверное даже это трудно будет представить!
Ну-ка? А теперь скажите, о чем думать программисту, о том, что на разных филиалах налоги считаются по разному алгоритму или о том на какой таблице какой индекс и какую одну таблицу с десятками миллионов записей как правильно сджойнить с другой таблицей с миллионами записей так чтобы сразу не парализовать работу?
Но это еще не все! А теперь, давайте взглянем на то, что над крупным проектом работаете не вы один а десятки других программистов и на логику БД завязаны сотни тысяч строк кода. Я умышленно сказал на логику БД а не на структуру БД.
Потому что если бы весь этот код был завязан на структуру БД, то у вас бы просто исчезла такая возможность что-то менять в структуре БД. А любой сбой в этих сотнях тысяч строк кода стоит миллионы денег, не забываем об этом, поэтому нельзя ничего из этого кода выводить из работоспособного состояния.
Поэтому выведение разумной части бизнес-логики на уровень СУБД, это далеко не прихоть, а суровая необходимость.
А в некоторых случаях единственно реально-доступная возможность, особенно, когда специально выделенный DBA занимается оптимизацией выполнения запросов, огранизацией хранения, резервирования, измением структуры, отказоустойчивостью БД, не вдаваясь в бизнес-логику, в которой он все равно нифига не поймет, в силу некомпетенции и в силу того, что он не смог бы ее окинуть взглядом. А созданием например, рабочего места для финдиректора, занимается программист, знающий что такое налоги, счета, договора и прочие вещи, в которые никогда не будет лезть DBA. А DBA может легко изменить структуру БД, например, по просьбе другого программиста, занимающегося, к примеру внутренней логистикой, не поломав при этом интерфейс БД.
Поэтому, пожалуйста, не делайте поспешных заявлений по поводу тех вещей в которых мало разбираетесь.
>>DBA занимается… измением структуры… не вдаваясь в бизнес-логику
Я с трудом представляю, как такое возможно. Только если структура не связана с бизнес-логикой, а это уже скорее NOSQL-решение.
То что вы описали гораздо проще решается трехзвенкой: абстрактное хранилище, которое вообще никак не завязано на бизнес-логику. Объектно-реляционная БД например. DBA будет проще его админить и сложнее поломать. Следующий уровень — вся бизнес логика. И последний — то самое отображение бизнес логики в виде красивой диаграмки для директора. Или отчета для менеджера. Смысл в том что нижние уровни не знают ничего о верхних. Соответственно и обслуживающие их работники не должны особо вникать в работу друг друга.
Если же хранилище перемешано с бизнес-логикой (Таблицы + ХП), а часть логики еще и в клиентском приложении — это поддерживать гораздо сложнее.
Несомненная область применения ХП — автоматизация абстрактных операций по обслуживанию хранилища.
Также, вынос части логики в ХП полезен в многопользовательских двухзвенных системах, т.к. здорово повышает производительность клиентского приложения за счет выноса сложных операций с данными на сервер.
Я с трудом представляю, как такое возможно. Только если структура не связана с бизнес-логикой, а это уже скорее NOSQL-решение.
То что вы описали гораздо проще решается трехзвенкой: абстрактное хранилище, которое вообще никак не завязано на бизнес-логику. Объектно-реляционная БД например. DBA будет проще его админить и сложнее поломать. Следующий уровень — вся бизнес логика. И последний — то самое отображение бизнес логики в виде красивой диаграмки для директора. Или отчета для менеджера. Смысл в том что нижние уровни не знают ничего о верхних. Соответственно и обслуживающие их работники не должны особо вникать в работу друг друга.
Если же хранилище перемешано с бизнес-логикой (Таблицы + ХП), а часть логики еще и в клиентском приложении — это поддерживать гораздо сложнее.
Несомненная область применения ХП — автоматизация абстрактных операций по обслуживанию хранилища.
Также, вынос части логики в ХП полезен в многопользовательских двухзвенных системах, т.к. здорово повышает производительность клиентского приложения за счет выноса сложных операций с данными на сервер.
Возможно я немного неточно выразился, насчет «не вдавание DBA в бизнес-логику». PL/SQL-процедуры и пакеты пишут программисты, хорошо владеющие бизнес-логикой верхнего уровня, а DBA им помогает сделать оптимально работающими.
Так, DBA работает с оптимизацией аггрегационных запросов которые оперируют с некоторым полем некой большой таблицы, данные в этом поле меняются некоторым job-ом, который запускается в конце каждого месяца. (DBA не сильно вдается в семантику что означает данное поле, но он помогает программистам сделать работу быстрой и надежной). Так например, возможным решением будет написание еще одной процедуры, запускающейся из первой, которая будет сохранять аггрегированные данные для дальнейшего интенсивного использования. (но это конечно на пальцах).
Насчет трехзвенки: Это хорошо, но к сожалению «трехзвенка не всегда серебрянная пуля».
Так, DBA работает с оптимизацией аггрегационных запросов которые оперируют с некоторым полем некой большой таблицы, данные в этом поле меняются некоторым job-ом, который запускается в конце каждого месяца. (DBA не сильно вдается в семантику что означает данное поле, но он помогает программистам сделать работу быстрой и надежной). Так например, возможным решением будет написание еще одной процедуры, запускающейся из первой, которая будет сохранять аггрегированные данные для дальнейшего интенсивного использования. (но это конечно на пальцах).
Насчет трехзвенки: Это хорошо, но к сожалению «трехзвенка не всегда серебрянная пуля».
Я вижу, что Вы меня превратно поняли. Понимаете, я написал о вынесении логики из Oracle, при чем здесь «монстрообразное неповоротливое приложение»? Все уже давно используют SOA. Я не очень понимаю, как все это вообще связано с непосредственно вынесением логики в PL/SQL.
Реально, из всей этой простыни текста я вынес только 1 технологический комментарий.
Я Вам отвечу — а Вы не джойньте. Денормализуйте данные, используйте map/reduce.
Не стоит искать проблемы там, где их нет. БД — это просто хранилище данных.
Вы, вероятно, вложили немало сил и времени в изучение Oracle, но иногда стоит взглянуть на проблему и под другим углом. Если этого не делать, то прогресса не будет.
Реально, из всей этой простыни текста я вынес только 1 технологический комментарий.
какую одну таблицу с десятками миллионов записей как правильно сджойнить с другой таблицей с миллионами записей так чтобы сразу не парализовать работу?
Я Вам отвечу — а Вы не джойньте. Денормализуйте данные, используйте map/reduce.
Не стоит искать проблемы там, где их нет. БД — это просто хранилище данных.
Вы, вероятно, вложили немало сил и времени в изучение Oracle, но иногда стоит взглянуть на проблему и под другим углом. Если этого не делать, то прогресса не будет.
Поверьте, я на любую проблему могу взглянуть «под другим углом» (кроме Oracle, мне известно дохрена еще разных технологий, а мозги у меня еще не настолько закостенели до состояния неспособности перерабатывать новую информацию, на пенсию я пока не собираюсь, btw).
И я из практики знаю, что существует оргомная масса задач, когда «умное хранилище» более оптимально чем «просто хранилище данных». Потому что я могут вам привести миллион примеров, когда добавление десяток-другой строчек в логику БД на PL/SQL можно эквивалентно решить, но решить десятком-другим ТЫСЯЧ СТРОК кода на прикладном уровне (разбросанного до кучи по разным модулям, поддерживаемым разными программистами).
Что и на что Джойнить/Не Джойнить вопрос оптимизации физической работы с БД, а не логической.
Простой пример:
Вам надо получить состояние взаиморасчетов с контрагентами по состоянию на конец позапрошлого месяца. Причем не просто так, а для дальнейшей обработки.
Вроде, плевое дело, в приложении пишем SQL-запрос, аггрегирующий проводки (к примеру).
Замечательно, когда данных мало, можно просто саггрегировать проводки, по конец заданного месяца и все будет замечательно работать. И этот кусок кода будет хорошо работать пока база не разрослась и количество проводок не стало исчисляться миллионами.
Ну, что все очень просто, скажете, достаточно изменить физическую структуру (где-то достаточно добавить готовое вычисленное для ускорения состояние взаиморасчетов на концы определенных периодов, где-то что-то добавить в таблицу, где-то что-то выкинуть..).
Но, вот тут и возникает ОФИГЕННАЯ СЛОЖНОСТЬ: запросов, работающих с физической структурой проводок туева хуча в сотнях тысяч строк, причем сбой в любой из них — сразу милионные убытки!
Так что, у вас героизма очень-бы поубавилось, если вас заставить отыскать в сотне-другой тысяч строк все места где хардкодом прошиты SQL-запросы к физической структуре. Большинство этих тысяч строк, заметим, даже не вы мантейните, а другие программисты, причем места эти могут быть настолько б-гом забытые, что даже «отвественные за них программисты» вам наверное скажут «да, меняй, вроде ничего не должно порушиться».
Так что еще раз вам повторяю — логика в СУБД — это не прихоть, а иногда просто необходимость.
Это другая методология взаимодействия с БД: не работа не с физической структурой (таблицами и полями), а работа с хранилищем как логической структурой — для вас БД это не хранилище таблиц и полей, а хранилище сущностей типа договоров, балансов, проводок (причем сущностей которые можно не только получить и записать, но и обладающие достаточно сложной внутренней логикой). Причем как оно будет отображено на «физический уровень хранения» может десять раз меняться.
А Теперь развею ваши иллюзии насчет логики БД и PL/SQL. Вы скажете, что эту самую логику отображения логических сущностей на физические таблицы можно выполнять и на прикладном уровне?
1) Да, конечно, можно. Но неоптимально, потому что две строки PL/SQL~100-1000 строк C++ (при этом не забываем, сколько потенциальных ошибок в них может содержаться, а каждая «ошибочка» стоит дохрена бабла).
2) Более существенны в «серьезном бизнесе» фактор «гетерогенности среды».
Представьте себе, с одной и той же базой данных работают из разных приложений на разных языках и разных местах.
Например, для клиентов существует «веб-кабинет клиента», где он может видеть относящуюся к мену часть работу через отдельный раздел веб-сайта (сайт писан на PHP).
Департамент логистики работает с данными через какую-то свою только им понятную хрень писанную каким-то тамошним умником на питоне.
С проводками по банку работает программа связанная с клиент-банком писанная на C.
Из склада с БД работают наладонники снабженные сканнером штрих-кода на которых крутиться Java-приложение (причем это Java-приложение писала сторонняя фарма)… и т.д., список можно продолжать.
А теперь, подумайте, вообще это реальная задача — взять и изменить просто так физическую структуру БД, НЕ СЛОМАВ ПРИ ЭТОМ ВСЕ?
Сможете ли вы легко «денормализовать данные» в такой реальной гетерогенной среде?
Боюсь, увы, молодой человек, вы сильно переоцениваете свои силы!
Да, наличие логики на уровне БД — это действительно другая методология (вам, как я вижу, методология неизвестная), но она действительно очень часто является чуть ли не лучшим из приемлемых решений.
И я из практики знаю, что существует оргомная масса задач, когда «умное хранилище» более оптимально чем «просто хранилище данных». Потому что я могут вам привести миллион примеров, когда добавление десяток-другой строчек в логику БД на PL/SQL можно эквивалентно решить, но решить десятком-другим ТЫСЯЧ СТРОК кода на прикладном уровне (разбросанного до кучи по разным модулям, поддерживаемым разными программистами).
Что и на что Джойнить/Не Джойнить вопрос оптимизации физической работы с БД, а не логической.
Простой пример:
Вам надо получить состояние взаиморасчетов с контрагентами по состоянию на конец позапрошлого месяца. Причем не просто так, а для дальнейшей обработки.
Вроде, плевое дело, в приложении пишем SQL-запрос, аггрегирующий проводки (к примеру).
Замечательно, когда данных мало, можно просто саггрегировать проводки, по конец заданного месяца и все будет замечательно работать. И этот кусок кода будет хорошо работать пока база не разрослась и количество проводок не стало исчисляться миллионами.
Ну, что все очень просто, скажете, достаточно изменить физическую структуру (где-то достаточно добавить готовое вычисленное для ускорения состояние взаиморасчетов на концы определенных периодов, где-то что-то добавить в таблицу, где-то что-то выкинуть..).
Но, вот тут и возникает ОФИГЕННАЯ СЛОЖНОСТЬ: запросов, работающих с физической структурой проводок туева хуча в сотнях тысяч строк, причем сбой в любой из них — сразу милионные убытки!
Так что, у вас героизма очень-бы поубавилось, если вас заставить отыскать в сотне-другой тысяч строк все места где хардкодом прошиты SQL-запросы к физической структуре. Большинство этих тысяч строк, заметим, даже не вы мантейните, а другие программисты, причем места эти могут быть настолько б-гом забытые, что даже «отвественные за них программисты» вам наверное скажут «да, меняй, вроде ничего не должно порушиться».
Так что еще раз вам повторяю — логика в СУБД — это не прихоть, а иногда просто необходимость.
Это другая методология взаимодействия с БД: не работа не с физической структурой (таблицами и полями), а работа с хранилищем как логической структурой — для вас БД это не хранилище таблиц и полей, а хранилище сущностей типа договоров, балансов, проводок (причем сущностей которые можно не только получить и записать, но и обладающие достаточно сложной внутренней логикой). Причем как оно будет отображено на «физический уровень хранения» может десять раз меняться.
А Теперь развею ваши иллюзии насчет логики БД и PL/SQL. Вы скажете, что эту самую логику отображения логических сущностей на физические таблицы можно выполнять и на прикладном уровне?
1) Да, конечно, можно. Но неоптимально, потому что две строки PL/SQL~100-1000 строк C++ (при этом не забываем, сколько потенциальных ошибок в них может содержаться, а каждая «ошибочка» стоит дохрена бабла).
2) Более существенны в «серьезном бизнесе» фактор «гетерогенности среды».
Представьте себе, с одной и той же базой данных работают из разных приложений на разных языках и разных местах.
Например, для клиентов существует «веб-кабинет клиента», где он может видеть относящуюся к мену часть работу через отдельный раздел веб-сайта (сайт писан на PHP).
Департамент логистики работает с данными через какую-то свою только им понятную хрень писанную каким-то тамошним умником на питоне.
С проводками по банку работает программа связанная с клиент-банком писанная на C.
Из склада с БД работают наладонники снабженные сканнером штрих-кода на которых крутиться Java-приложение (причем это Java-приложение писала сторонняя фарма)… и т.д., список можно продолжать.
А теперь, подумайте, вообще это реальная задача — взять и изменить просто так физическую структуру БД, НЕ СЛОМАВ ПРИ ЭТОМ ВСЕ?
Сможете ли вы легко «денормализовать данные» в такой реальной гетерогенной среде?
Боюсь, увы, молодой человек, вы сильно переоцениваете свои силы!
Да, наличие логики на уровне БД — это действительно другая методология (вам, как я вижу, методология неизвестная), но она действительно очень часто является чуть ли не лучшим из приемлемых решений.
NVL — это функция PL/SQL, следовательно снова будет переключение кон текстов. Поэтому ее следует заменить на COALESCE или оператор CASE.
O_o, ткните меня в документацию, где это написано.
И да, имхо, PLSQL — ужасный язык, как будто нарочно придуманный для индусов, которым платят за код посимвольно.
Спасибо, за ваш коментаррий.
Формально вы правы. (Документация это подтверждает). Правильно было бы написать, что она ведет себя как функция PL/SQL со всеми вытекающими.
Я все же позволю объяснить почему написал именно так.
Возьмем NVL — это функция двух аргументов. Очевидно что с некторым старанием ее можно заменить на COALESCE, DECODE, CASE выражение.
Самое главное отличе NVL от этих трех решений в том что аргументы NVL вычисляются всегда (а теперь представьте что там запросы с аггрегацией миллионов строк), что очень похоже на PL/SQL функции. Другие три решения этим недостатком не страдают.
Формально вы правы. (Документация это подтверждает). Правильно было бы написать, что она ведет себя как функция PL/SQL со всеми вытекающими.
Я все же позволю объяснить почему написал именно так.
Возьмем NVL — это функция двух аргументов. Очевидно что с некторым старанием ее можно заменить на COALESCE, DECODE, CASE выражение.
Самое главное отличе NVL от этих трех решений в том что аргументы NVL вычисляются всегда (а теперь представьте что там запросы с аггрегацией миллионов строк), что очень похоже на PL/SQL функции. Другие три решения этим недостатком не страдают.
А по-моему, PL/SQL чудесное дитя ADA ;) Ну я олдфаг, да. Но я нахожу его очень логичным и приятным.
Да комментаторы правы. Писать код на допотопном неудобном языке — это же ужас какой-то. Сейчас всю логику можно вынести на уровень приложения, а не так, что половина кода в БД, другая половина в приложении. Это все радикально усложняет. А если вам надо вызвыать какую-то функцию в приложении при изменении данных в таблице БД, а? А перенести часть выборок данных в кеш?
Код в БД, говорят, неудобно отлаживать, var_dump() не сделаешь например.
Вконтакте и facebook обходятся без всех этих дорогущих проприетарных систем, и джойнов на 6 таблиц, и прекрасно выдерживают огромные нагрузки.
Код в БД, говорят, неудобно отлаживать, var_dump() не сделаешь например.
Вконтакте и facebook обходятся без всех этих дорогущих проприетарных систем, и джойнов на 6 таблиц, и прекрасно выдерживают огромные нагрузки.
Трехзвенка не всегда удобна, и по-определению менее производительна. Тем не менее, в целом с вами согласен. Бизнес-логику в СУБД довольно накладно поддерживать и сопровождать.
«допотопном неудобном языке» — убейся об стену, школие.
Лучше SQLя для сложных выборок данных не существует, это факт. Но процедурная его разновидность (PL/SQL, TransactSQL, PSQL) — не выдерживает никакого сравнения даже с С++, не говоря уже про C#, Java и прочие.
Тут кстати интересен подход PostgreSQL — ХП можно писать хоть на С++, хоть на Java, хоть на Perl.
Тут кстати интересен подход PostgreSQL — ХП можно писать хоть на С++, хоть на Java, хоть на Perl.
Знаешь, сейчас перед моими глазами пронеслись тонны документации на Pro*C, мегатонны
косяков в дата-провайдеров для C#, C++ и для Java.
Так вот, PL/SQL — душечка!
Например, пока данные простые, то дата-провайдеры справляются нормально, но как только данные
немного неестественны (всякие XML, геометрии и прочее) вот тут-то начинается «секс по испански»!
P.S. Извини за стену и школие, но не стоит делать резких заявлений даже в той области, в которой кажется, ты все уже знаешь.
косяков в дата-провайдеров для C#, C++ и для Java.
Так вот, PL/SQL — душечка!
Например, пока данные простые, то дата-провайдеры справляются нормально, но как только данные
немного неестественны (всякие XML, геометрии и прочее) вот тут-то начинается «секс по испански»!
P.S. Извини за стену и школие, но не стоит делать резких заявлений даже в той области, в которой кажется, ты все уже знаешь.
В Oracle также есть возможность писать ХП на других языках:
— C c версии Oracle 8.0
— Java c версии Oracle 8.1.5
Есть, кажется, поддержка еще нескольких языков, но, дабы не дезинформировать, ограничусь двумя.
— C c версии Oracle 8.0
— Java c версии Oracle 8.1.5
Есть, кажется, поддержка еще нескольких языков, но, дабы не дезинформировать, ограничусь двумя.
Pro*ADA
Pro*C/C++
Pro*COBOL
Pro*FORTRAN
Pro*PL/1
ке-ке-ке
Pro*C/C++
Pro*COBOL
Pro*FORTRAN
Pro*PL/1
ке-ке-ке
«Код в БД, говорят, неудобно отлаживать, var_dump() не сделаешь например.»
Вас обманули, есть несколько отладчиков для PL/SQL, нормально там все с этим.
Вас обманули, есть несколько отладчиков для PL/SQL, нормально там все с этим.
Написали про «булку», напишите про LIMIT ;) А то PGA/UGA не резиновый.
А так, да, начинающим полезно почитать такие статьи, согласен на 100%
И еще забавно у Вас параметры обозваны (в смысле не привычно для меня): foo_in, bar_in
Я привык писать p_foo,p_var для параметров, и v_foo, v_bar бар для переменных, но пусть бросит меня кто камень, если я пытаюсь разжечь тут холивар.
А так, да, начинающим полезно почитать такие статьи, согласен на 100%
И еще забавно у Вас параметры обозваны (в смысле не привычно для меня): foo_in, bar_in
Я привык писать p_foo,p_var для параметров, и v_foo, v_bar бар для переменных, но пусть бросит меня кто камень, если я пытаюсь разжечь тут холивар.
Е-мае… Что за бред-то… Этот топик надо было назвать «как делать нельзя».
1. Т.Кайта не читали? если можно сделать одним SQL-запросом — надо делать одним запросом:
2. где for update? Согласованность вам вообще побоку?
3. NVL нет в SQL? Вы в своем уме?
4. Вы знаете что с опр. версий for… in (select...) обрабатывает группами?
5. «Стоит также взять за правило помещать SQL операторы в отдельные процедуры и функции» — вы знаете что такое SQL операторы? и зачем вы их в отдельные процедуры и функции хотите запихнуть?
6. Все пихать в коллекции — вы представляете каких они размеров могут быть?
7. И всерьез считаете, что вот такие извраты разбиения одного SQL-запроса в процедуре быстрее чем один запрос и всегда? Вам ДБА еще не собираются голову оторвать?
7. Говорили об именования и оформлении кода — Так что за мрачный и страшный код пишите?
8. «Намеренно не освещены такие темы как обработка ошибок и логирование, CBO оптимизация запросов. Если будет интересно освещу эти моменты.» — ой ну конечно же… куда Кайту, Льюису и Фейерштейну до вас… У вас все в одном топике уместится…
1. Т.Кайта не читали? если можно сделать одним SQL-запросом — надо делать одним запросом:
UPDATE employee
SET salary = NVL(&newsal_in, 1000)
WHERE department_id = &department_in
2. где for update? Согласованность вам вообще побоку?
3. NVL нет в SQL? Вы в своем уме?
4. Вы знаете что с опр. версий for… in (select...) обрабатывает группами?
5. «Стоит также взять за правило помещать SQL операторы в отдельные процедуры и функции» — вы знаете что такое SQL операторы? и зачем вы их в отдельные процедуры и функции хотите запихнуть?
6. Все пихать в коллекции — вы представляете каких они размеров могут быть?
7. И всерьез считаете, что вот такие извраты разбиения одного SQL-запроса в процедуре быстрее чем один запрос и всегда? Вам ДБА еще не собираются голову оторвать?
7. Говорили об именования и оформлении кода — Так что за мрачный и страшный код пишите?
8. «Намеренно не освещены такие темы как обработка ошибок и логирование, CBO оптимизация запросов. Если будет интересно освещу эти моменты.» — ой ну конечно же… куда Кайту, Льюису и Фейерштейну до вас… У вас все в одном топике уместится…
Зачему трололо устраивать?
Вопросы можно задавать и в более спокойном тоне.
1. В топике написано, что эта функция пример.
2. Согласен, но опять же это пример.
3. Я же написал, что NVL — это функция SQL, со специфичным поведением.
4. Прекрасно знаю, только это тут ни причем.
5. Первый мой комментарий
6. Был комментарий про LIMIT.
7. См. 1 и 2. В реали такого ни кто не пишет
7. Очень большой и мрачный. Связан с FlexCube
8. Мне кажется очевидно, что это в вводную статью не запихать.
Вопросы можно задавать и в более спокойном тоне.
1. В топике написано, что эта функция пример.
2. Согласен, но опять же это пример.
3. Я же написал, что NVL — это функция SQL, со специфичным поведением.
4. Прекрасно знаю, только это тут ни причем.
5. Первый мой комментарий
6. Был комментарий про LIMIT.
7. См. 1 и 2. В реали такого ни кто не пишет
7. Очень большой и мрачный. Связан с FlexCube
8. Мне кажется очевидно, что это в вводную статью не запихать.
О боже… Помимо всего этого вы еще procedure функциями называете и не отличаете функции от выражений… Как бы вообще то ни было, не можете написать адекватный пример — не беритесь.
В следующий раз обязательно возьму более жизненные примеры.
Изначальный пример был взят у С. Фейерштейна.
Изначальный пример был взят у С. Фейерштейна.
К следующему разу хотя бы выучите работу с коллекциями:
Вместо
лучше member of или in (select column_value from table(...))
Вместо
FORALL indx IN deptlist.FIRST..deptlist.LAST
UPDATE employee
SET salary = COALESCE(newsal_in, 1000)
WHERE employee_id = deptlist(indx);
лучше member of или in (select column_value from table(...))
Мне кажется стоит заканчивать это.
Причем тут
Способ для обхода колеекции по одной (или даже группами) с помощью
Причем тут
member of? Он только проверки наличия элемента в колеекцииСпособ для обхода колеекции по одной (или даже группами) с помощью
for ... in (...) не быстрее — так обрабатывается только небольшая группа, а с FORALL все. Если уверены в обратном с вас trace файл с доказательством или хотя бы логи профайлера.1. «FORALL indx IN deptlist.FIRST..deptlist.LAST» с апдейтом и простой апдейт — вы все еще против Кайта?
2. Forall и For — Корреляцию размера группы с разницей в пожираемых ресурсах совсем не понимаете? То есть limit в forall кляузе они ввели чисто для прикола?
PS. Пожалуй, действительно стоит это заканчивать, если сейчас не понимаете, то и учить смысла не вижу. Если захотите, то почитаете.
Всего.
2. Forall и For — Корреляцию размера группы с разницей в пожираемых ресурсах совсем не понимаете? То есть limit в forall кляузе они ввели чисто для прикола?
PS. Пожалуй, действительно стоит это заканчивать, если сейчас не понимаете, то и учить смысла не вижу. Если захотите, то почитаете.
Всего.
CREATE TYPE id_list IS TABLE OF INTEGER;
Oracle не делает разницы между IS и AS,
но мне кажется читабельнее такой вариант:
CREATE TYPE id_list AS TABLE OF INTEGER;
Oracle не делает разницы между IS и AS,
но мне кажется читабельнее такой вариант:
CREATE TYPE id_list AS TABLE OF INTEGER;
Очень хорошая книга по теме Кониор МакДональд. Oracle PL/SQL для профессионалов. Практические решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хорошие привычки в PL/SQL