История изменений
Исправление ergo, (текущая версия) :
далекие 15 лет назад, когда деревья были выше, а трава зеленее, разработка логики в хранимых процедурах была нормой. для этого даже свои IDE были. беда только в том, что редактор кода работал с базой напрямую и валидация,тестирование и дебаггинг были через сохранение этого кода в саму базу. т.е. это было ни разу не редактирование файла,который бы можно было сразу же коммитить в какой-нибудь svn, это значит нужно было вручную сохранить это в файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, то знаете, где таких хранимок достаточное количество (в моем случае это было 2 или 3 сотни), а если часть из них еще и увесистые (в моем случае это в районе 1К строк на хранимку), то масшаб возни с файлами и svn/git просто запредельный. вот в этом не просто очень большая проблема, а просто ГИГАНТСКАЯ проблема. это вам не миграции по добавлению или удалению нескольких строчек написать. масштаб другой. я эту боль проходил, так что пишу это не с чьих-то слов, а имея достаточный опыт судить об этом.
ПС: да, я уже не говорю про проблемы масштабирования такого подхода. в те времена были вынуждены использовать mat.view для этого, но они имел свойство ломаться (мы, конечно подпирали костылем в виде полного рефреша раз в несколько часов, но это была боль, как ни крути). так что, извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.
ППС: ой, совсем же забыл про деплой. это же отдельная сказка. стоит только чуть-чуть упустить из виду мелочь, которая инвалидирует твою процедуру как все зависимые объекты инвалидировались и нужно было рекомпилять весь этот колхоз вручную. извиняюсь, но в это ад обратно я не вернусь, а если контора скажет заниматься этим мазахизмом - сорян, это будет поледний день работы в этом болоте.
Исправление ergo, :
далекие 15 лет назад, когда деревья были выше, а трава зеленее, разработка логики в хранимых процедурах была нормой. для этого даже свои IDE были. беда только в том, что редактор кода работал с базой напрямую и валидация,тестирование и дебаггинг были через сохранение этого кода в саму базу. т.е. это было ни разу не редактирование файла,который бы можно было сразу же коммитить в какой-нибудь svn, это значит нужно было вручную сохранить это в файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, то знаете, где таких хранимок достаточное количество (в моем случае это было 2 или 3 сотни), а если часть из них еще и увесистые (в моем случае это в районе 1К строк на хранимку), то масшаб возни с файлами и svn/git просто запредельный. вот в этом не просто очень большая проблема, а просто ГИГАНТСКАЯ проблема. это вам не миграции по добавлению или удалению нескольких строчек написать. масштаб другой. я эту боль проходил, так что пишу это не с чьих-то слов, а имея достаточный опыт судить об этом.
ПС: да, я уже не говорю про проблемы масштабирования такого подхода. в те времена были вынуждены использовать mat.view для этого, но они имел свойство ломаться (мы, конечно подпирали костылем в виде полного рефреша раз в несколько часов, но это была боль, как ни крути). так что, извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.
ППС: ой, совсем же забыл про деплой. это же отдельная сказка. стоит только чуть-чуть упустить из виду мелочь, которая инвалидирует твою процедуру как все зависимые объекты инвалидировались и нужно было рекомпилять весь этот колхоз вручную.
Исправление ergo, :
далекие 15 лет назад, когда деревья были выше, а трава зеленее, разработка логики в хранимых процедурах была нормой. для этого даже свои IDE были. беда только в том, что редактор кода работал с базой напрямую и валидация,тестирование и дебаггинг были через сохранение этого кода в саму базу. т.е. это было ни разу не редактирование файла,который бы можно было сразу же коммитить в какой-нибудь svn, это значит нужно было вручную сохранить это в файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, то знаете, где таких хранимок достаточное количество (в моем случае это было 2 или 3 сотни), а если часть из них еще и увесистые (в моем случае это в районе 1К строк на хранимку), то масшаб возни с файлами и svn/git просто запредельный. вот в этом не просто очень большая проблема, а просто ГИГАНТСКАЯ проблема. это вам не миграции по добавлению или удалению нескольких строчек написать. масштаб другой. я эту боль проходил, так что пишу это не с чьих-то слов, а имея достаточный опыт судить об этом.
ПС: да, я уже не говорю про проблемы масштабирования такого подхода. в те времена были вынуждены использовать mat.view для этого, но они имел свойство ломаться (мы, конечно подпирали костылем в виде полного рефреша раз в несколько часов, но это была боль, как ни крути). так что, извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.
Исходная версия ergo, :
далекие 15 лет назад, когда деревья были выше, а трава зеленее, разработка логики в хранимых процедурах была нормой. для этого даже свои IDE были. беда только в том, что редактор кода работал с базой напрямую и валидация,тестирование и дебаггинг были через сохранение этого кода в саму базу. т.е. это было ни разу не редактирование файла,который бы можно было сразу же коммитить в какой-нибудь svn, это значит нужно было вручную сохранить это в файл и потом уже проводить все необходимые манипуляции. если вы работали с большими проектами, где таких хранимок было достаточное количество (в моем случае это было 2 или 3 сотни), а часть из них была увесистой (в районе 1К строк на хранимку), то масшаб возни с файлами и svn был запредельный. вот в этом не просто очень большая проблема, а просто ГИГАНТСКАЯ проблема. это вам не миграции по добавлению или удалению нескольких строчек написать. масштаб другой. я эту боль проходил, так что пишу это не с чьих-то слов, а имея достаточный опыт судить об этом.
ПС: да, я уже не говорю про проблемы масштабирования такого подхода. в те времена были вынуждены использовать mat.view для этого, но они имел свойство ломаться (мы, конечно подпирали костылем в виде полного рефреша раз в несколько часов, но это была боль, как ни крути). так что, извиняюсь, но ни один довод сейчас меня не убедит использовать хранимые процедуры. только штатные функции аналитики sql для выборки данных.