АА
"хранимая процедура".
ктото когдато в какойто книжке перевел "stored procedure"
ктото когдато в какойто книжке перевел "stored procedure"
ранимая процедура, 😷
Size: a a a
2020 August 26
MS
если ты про fragile то да 🙂
МК
ну т.е. логика в одном месте лучше чем в двух
Ага. Реально всю логику вынести из базы, но нереально всю логику реализовать внутри. ОК. Понято.
A
ну и IDE нормальных для них нет. И навигации удобной (я слишком привык к Ctrl+Click по названию фкнции - и ты в нее переносишься). И дебага нет! как ты хранимку step by step посмотришь..
A
ну и то что сказал Макс
AR
для оракла и mssql чето есть
toad тот же
toad тот же
GL
ну и IDE нормальных для них нет. И навигации удобной (я слишком привык к Ctrl+Click по названию фкнции - и ты в нее переносишься). И дебага нет! как ты хранимку step by step посмотришь..
ну это уже проблема sql на самом деле ) декларативный язык же
A
нас легион ахахахахаха (смеется демонически)
"динамически"
AR
"динамически"
не. статически )))
AR
кстати, у меня будет навигация по cmd+click ) ну почти. я когда паршу ddl, сохраняю все позиции для объектов. все create, alter и тд. чтоб потом можно было посмотреть все упоминания во всех файлах
AR
Ага. Реально всю логику вынести из базы, но нереально всю логику реализовать внутри. ОК. Понято.
да не, все реально. просто при отсутсвии тулинга страдать со второым вариантом приходится гораздо больше
МК
В тоаде есть и дебаг кой-какой и и ctrl+клик, и куча всякого
МК
Но общую идею я понял
AR
ну я и говорю, оракл это отлельный мир, там чего только нет
IV
есть хороший кейс, когда ты вьюхи заменяешь на хранимки, написаные на чистом sql. это будет работать намного эффективнее, чем селект из вьюхи, с последующей фильтрацией.
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
Почему селект в SP будет работать эффективнее чем селект во вьюхе?
AR
Почему селект в SP будет работать эффективнее чем селект во вьюхе?
я ж показывал тебе этот кейс ) разговор о том, что можено сделать SQL-функцию (не plpgsql), которая принимает параметры и подставляет из в where. это будет быстрее, чем делать селект с этим where из вьюхухи. т.к. в первом случае могут быть использованны индексы, будет инпользованно меньше памяти и тд. если селектить из вьюхи ты получишь все данные в оперативу, и будешь в оперативе искать. НО если результат большой, то скорее всего посгря постесняется результат селекта из вьюхи класть в оперативу и благополучно засвопит его на диск
AR
select * from view_fn(1)
будет быстрее, чем select * from view where a = 1
будет быстрее, чем select * from view where a = 1
MM
select * from view_fn(1)
будет быстрее, чем select * from view where a = 1
будет быстрее, чем select * from view where a = 1
Чёт это спорно, мне казалось, что pg оптимизирует такие случаи
СА
Всем привет! Ищу готовое решение для разметки датасетов картинок и видео. Сначала нашёл https://github.com/l3p-cv/lost, и понравился, но потом внезапно попал в https://github.com/jsbroks/awesome-dataset-tools , и теперь как та мартышка, боюсь разорваться. Кто уже что-то из этого списка использовал и может рекомендовать/отсоветовать? Спасибо!
IV
select * from view_fn(1)
будет быстрее, чем select * from view where a = 1
будет быстрее, чем select * from view where a = 1
