Я наверно стар, парни. Ещё в оракл все через пакеты хранимых делали. Не люблю когда логику и ещё большую пишут в самом веб приложении

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

Против точечного применения там где сильно нужно я не против

Просто вдруг начальник придёт и скажет переписывайте всю морду на nodejs. И всю логику переделывать. А так по опыту. Базу редко меняют. А вот приложения меняются.

команда сишников за 1 день перешла на nodejs

ОК!

команда qa за 1 день перешла на scala

ОК!

Я наверно стар, парни. Ещё в оракл все через пакеты хранимых делали. Не люблю когда логику и ещё большую пишут в самом веб приложении

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

Я наверно стар, парни. Ещё в оракл все через пакеты хранимых делали. Не люблю когда логику и ещё большую пишут в самом веб приложении

Ух. У меня на прошлой работе такое было. Все равно в веб приложении логика появлялась

Я в 00х сталкивался с проектом, в котором вся бизнес-логика была на pl/pgsql, и что-то у меня не очень хорошие впечатления остались от всего этого

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

ну теоретически можно делать миграции на уровне SQL файлов

а чего. мы писали миграции, норм всё.

прям на sql

а чего. мы писали миграции, норм всё.

Имеется ввиду наверное логика в SQL

Но думаю с сохранением инфы о текущей версии не составит труда

Тоесть доп таблица

хранимки вообще просто дропаешь и новые накатываешь

Хорошо это или плохо…

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

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

Базы не сохранял в репозитария, обычно просто backup. И с них же восстанавливали когда нужно. Переносили с дева на прод смотря какая бд, но фактически ручками или через dblink часть и другими способами.

ну теоретически можно делать миграции на уровне SQL файлов

Ну я такой подход видел, да. Получается в каждой миграции полный код всех измененных процедур

да

а как иначе то?

Тут в базах нет таких изменений как у исходниках

Ну я такой подход видел, да. Получается в каждой миграции полный код всех измененных процедур

и в чем проблема? ты же приложение целиком обновляешь

Да и не должны. Там сто раз отмерь, один раз отрежь)

В отличие от приложений. Где хотели появляются каждый день)

и в чем проблема? ты же приложение целиком обновляешь

А с локами при пересоздании процедур проблем точно не будет? Меня еще смущает, что никакого canary testing не сделать при таком подходе

А с локами при пересоздании процедур проблем точно не будет? Меня еще смущает, что никакого canary testing не сделать при таком подходе

Ну там есть разные подходы. Оракл позволяет например две копии процедур держать, но я тут уже не шарю

А с локами при пересоздании процедур проблем точно не будет? Меня еще смущает, что никакого canary testing не сделать при таком подходе

А что не так с тестированием? Мы обязательно гоняли все процедуры так же как обычный софт

И оракл их компилирует

А что не так с тестированием? Мы обязательно гоняли все процедуры так же как обычный софт

canary testing это когда новую версию видят например только 5% пользователей

А. В этом смысле

Ну такого у нас не было. мы продукт пилили, а не сервис

canary testing это когда новую версию видят например только 5% пользователей

Это на уровне конечного приложения думаю можно сделать. В бд думать только о данных. И ничего более

Я наверно стар, парни. Ещё в оракл все через пакеты хранимых делали. Не люблю когда логику и ещё большую пишут в самом веб приложении

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

серверная логика должна быть на серверной части

и к субд это не имеет никакого отношения

субд это данные хранить

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

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

серверная логика в моем примере - часть субд Оракл.

Есть клиенты, есть сервер (он же субд)

Если так брать на оракл можно и сайт поднять) ну страничку.

Если так брать на оракл можно и сайт поднять) ну страничку.

Видел я такое. Жесть

Прям html в базе генерили

И базы разные согласен. С nosql вообще нет хранимых, там spark. С хранимыми только оракл или постгре

В тех примерах, которые я видел, в процедурах была еще и бизнес-логика

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

а это уже не просто интерфейс хранилища

В тех примерах, которые я видел, в процедурах была еще и бизнес-логика

аналогично, реальные задачи, работающие у 12 сотовых провайдеров по всему бывшему СССР

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

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

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

Не все уходят в микросервисы. Зачастую начинают и не замечают как появился монолит. Которую стало тяжело поддерживать.

И базы разные согласен. С nosql вообще нет хранимых, там spark. С хранимыми только оракл или постгре

Spark же вроде не очень годится чтобы обслуживать пользователей

обработку данных надо сделать внутри базы. Но логику туда засовывать не надо

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

Ну получается, что у нас бизнес-логика так или иначе будет размазана между приложением и субд

Spark же вроде не очень годится чтобы обслуживать пользователей

Напрямую с ним пользователи не работают. Со спарком работать только для обработки больших данных на фоне. А потом пересохранить весь чистый результат в отдельную таблицу, а там уже джанго например с ОРМ возьмёт быстро и просто

Напрямую с ним пользователи не работают. Со спарком работать только для обработки больших данных на фоне. А потом пересохранить весь чистый результат в отдельную таблицу, а там уже джанго например с ОРМ возьмёт быстро и просто

Ну для этого можно spark, да. Но такой подоход имеет очень ограниченное применение

есть какой нибудь асинхронный таймер, который выполняется параллельно с выполнением комманды? что то типо timer.start() update_file() timer.stop() print(timer.get_time)

Ну получается, что у нас бизнес-логика так или иначе будет размазана между приложением и субд

Тут уже золотая середина комбинация всех методов от задач. Все хорошо и все плохо, если баланса нет. Я думаю

ERROR: S client not available

есть какой нибудь асинхронный таймер, который выполняется параллельно с выполнением комманды? что то типо timer.start() update_file() timer.stop() print(timer.get_time)

называется "взять текущее время"

взял текущее время, сделал что хотел, еще раз взял время и сравнил

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

А insert из процедуры чем-то принципиально лучше insert'а из приложения? Ну кроме сетевого round-trip'а

эксель же,

Был опыт. Данным вроде можно было указывать тип. Помню у меня так числа как строки выводились. В документации поищи типы.

Был опыт. Данным вроде можно было указывать тип. Помню у меня так числа как строки выводились. В документации поищи типы.

наверно я не внимательно читал, спасибо, посмотрю сейчас

наверно я не внимательно читал, спасибо, посмотрю сейчас

Это было давно, я наверно введу тебя в заблуждение. Лучше перепроверю сейчас)

наверно я не внимательно читал, спасибо, посмотрю сейчас

Посмотри тут. https://github.com/python-excel/xlwt/blob/master/examples/num_formats.py

Посмотри тут. https://github.com/python-excel/xlwt/blob/master/examples/num_formats.py

ок, спасибо

А insert из процедуры чем-то принципиально лучше insert'а из приложения? Ну кроме сетевого round-trip'а

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

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

Это какое-то голословное утверждение. А что делать с субд, в которых нет процедур? Получается все пользователи nosql обречены на использование неграмотно спроектированных структур?

Это какое-то голословное утверждение. А что делать с субд, в которых нет процедур? Получается все пользователи nosql обречены на использование неграмотно спроектированных структур?

В приложении есть data access layer, все инсерты в нем, код снаружи о них не знает. И процедуры не нужны.

Вспомните декомпозицию и нормализацию в субд. тоже самое применяется и к приложению: Если приложению нужно читать данные - дайте ему набор view с описанием интерфейса. Нужно модифицировать данные - дайте ему интерфейс для изменения данных, а вся логика по подификации должна лежать в одном месте. А приложение должно обращаться к этому интерфейсу, дергая нужные методы и передавая для них данные. Отвечая на выше заданный вопрос. Голословное заявление это только длят тех что не знаком с понятием нормализации.

В приложении есть data access layer, все инсерты в нем, код снаружи о них не знает. И процедуры не нужны.

Ну я как раз с таким подходом согласен

Вспомните декомпозицию и нормализацию в субд. тоже самое применяется и к приложению: Если приложению нужно читать данные - дайте ему набор view с описанием интерфейса. Нужно модифицировать данные - дайте ему интерфейс для изменения данных, а вся логика по подификации должна лежать в одном месте. А приложение должно обращаться к этому интерфейсу, дергая нужные методы и передавая для них данные. Отвечая на выше заданный вопрос. Голословное заявление это только длят тех что не знаком с понятием нормализации.

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

Хранимых процедуры относятся только к sql, postgre и Oracle. Nosql играет по своим правилам

в примере дениса отдельный модуль работы с бд - data access layer, в проектах на Оракле - это все позволяет делать сам Оракл, в других СУБД, без пакетов и функций, вам все равно придется делать один модуль (если конечно вы ходите поддерживать этот один модуль, а не все места где есть работа с базой). Например в колонку таблицы N добавляется новое поле.

Пробовал cassandra. Вроде sql поддержка есть, а считай нет. Было странно.

Всем привет народ! Кто-нить разбирается в redis-е? Я установил дополнительный модуль rejson, и хочу засетить словарик в виде json объекта rj = Client(host='localhost', port=6379, db=1, decode_responses=True) ob1 = { 'фывфыв': 42 } rj.jsonset('Ключ', Path.rootPath(), obj1) Если запросит его обратно то получаем print( rj.jsonget('Ключ') ) {'Ñ\x84Ñ\x8bвÑ\x84Ñ\x8bв': 42} Что -то с кодировкой, можт кто сталкивался?

исходник в какой кодировке?

Всем привет народ! Кто-нить разбирается в redis-е? Я установил дополнительный модуль rejson, и хочу засетить словарик в виде json объекта rj = Client(host='localhost', port=6379, db=1, decode_responses=True) ob1 = { 'фывфыв': 42 } rj.jsonset('Ключ', Path.rootPath(), obj1) Если запросит его обратно то получаем print( rj.jsonget('Ключ') ) {'Ñ\x84Ñ\x8bвÑ\x84Ñ\x8bв': 42} Что -то с кодировкой, можт кто сталкивался?

Версия питона?

Какой исходник? Python 3.6

файл который ты запускаешь

твой

питоновский

и ещё: какая ОС?

обычный файл в pycharm redis.py OC Mac os

в примере дениса отдельный модуль работы с бд - data access layer, в проектах на Оракле - это все позволяет делать сам Оракл, в других СУБД, без пакетов и функций, вам все равно придется делать один модуль (если конечно вы ходите поддерживать этот один модуль, а не все места где есть работа с базой). Например в колонку таблицы N добавляется новое поле.

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