Информация об изменениях

Сообщение Re[7]: вопрос про пакеты от 02.02.2019 16:42

Изменено 02.02.2019 17:14 IZM

Re[7]: вопрос про пакеты
K>кстати. на кой хрен вообще ввели эту концепцию пакетов? ведь такой бардак получается в итоге. особенно если без стандартизации плодить эти пакеты на протяжении многих лет.
А что лучше чтоб валялась куча процедур и функций? вот тогда точно будет полный бардак. и это Вам никто не запрещает делать — не плодите пакеты и все.
На много удобнее когда функции и процедуры относящиеся к определенным задачам лежат в одном месте (как вариант для не любителей пакетов — использовать разные схемы, но там будут опять же претензии к раздаче прав).
раздать права на много функций и процедур намного трудозатратнее чем на пакет.
В пакете можно делать реализовывать полиморфизм.
Можете формировать глобальные переменные (значение которых ,например, использовать в одной сессии)
Вообщем там много чего полезного, относительно отдельных функций и процедур.

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

Не хотите раздавать права — работайте в одной схеме и Сonnect к БД делайте от имени схемы — никаких раздач прав не потребуется.
Раздача прав на колонку — это очень полезная вещь ,например, есть у Вас таблица, а значения колонок некоторых вы не желаете показывать некоторым личностям (Найти применение проблем нету)
Разделение на Pl/Sql и Sql — каждый движок оптимизирован под свои задачи, так что свои плюсы есть.

поработаете — полюбите у всех свои плюсы и минусы.
Мне, например, У FireBird нравятся некоторые фишки — к процедурам можно обращаться как к таблицам (они там могут табличный вывод делать), в Оracle приходится возвращать табличный тип для такой реализации и куда больше кода писать.
Re[7]: вопрос про пакеты
K>кстати. на кой хрен вообще ввели эту концепцию пакетов? ведь такой бардак получается в итоге. особенно если без стандартизации плодить эти пакеты на протяжении многих лет.
А что лучше чтоб валялась куча процедур и функций? вот тогда точно будет полный бардак. и это Вам никто не запрещает делать — не плодите пакеты и все.
На много удобнее когда функции и процедуры относящиеся к определенным задачам лежат в одном месте (как вариант для не любителей пакетов — использовать разные схемы, но там будут опять же претензии к раздаче прав).
раздать права на много функций и процедур намного трудозатратнее чем на пакет.
В пакете можно реализовывать полиморфизм (перегрузку функций и процедур).
Можете формировать глобальные переменные (значение которых ,например, использовать в одной сессии)
Вообщем там много чего полезного, относительно отдельных функций и процедур.

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

Не хотите раздавать права — работайте в одной схеме и Сonnect к БД делайте от имени схемы — никаких раздач прав не потребуется.
Раздача прав на колонку — это очень полезная вещь ,например, есть у Вас таблица, а значения колонок некоторых вы не желаете показывать некоторым личностям (Найти применение проблем нету)
Разделение на Pl/Sql и Sql — каждый движок оптимизирован под свои задачи, так что свои плюсы есть.

поработаете — полюбите у всех свои плюсы и минусы.
Мне, например, У FireBird нравятся некоторые фишки — к процедурам можно обращаться как к таблицам (они там могут табличный вывод делать), в Оracle приходится возвращать табличный тип для такой реализации и куда больше кода писать.