Работаю в с базами oracle. Очень тут любят пакеты. И это иногда очень удобно и круто. Но когда разрабов много. И изменений много. Всего приходится придумывать костыли на нактки дороботок. Тестирования отката. Про гит вообще боль. Но иногда через бд решить заду быстрее и дешевле
По поводу гит. Что мне приходит в голову - хранить процедуры в файликах, и в мёрж реквестах накатывать нужную хранимку хукрм гита. А ручное накатывания запретить обычным разрабам, через контроль доступа.
Ага видел как это быстро и удобно. Когда перенести изменения с теста (одного из 5) на прод, это тот ещё квест. В то время как с кодом это нажатие одной кнопки. 😂
Недостатком среды разработки SQL server management studio является отсутствие возможности структурировать файлы в виде папок. Все хранимые процедуры в ряд, функции и таблицы тоже. Приходится выходить из положения через использование префиксов в наименованиях. Но все равно потом накапливается много и приходится много листать, что очень не удобно. Насчёт контроля версий. Код процедур хранится в системных таблицах SQL Server и довольно легко можно автоматизировать журналировние всех изменений в их определениях.
Все есть, и git и unit test и даже ООП в некоторой степени. Использование кода в БД несколько улучшает обстановку с безопасностью, но увеличивает сложность. Бизнес логика часто размазывается между бэком и в БД. Не все можно сделать или не все удобно делать в ДБ. Если у вас есть хоть какая-то интеграция в приложении (печать, передача файла, импорт, настройки, аутентификация, разные web интеграции и тд и тп) это все по любому будет работать на бэке. Защита, обработка данных более эффективна и правильна в БД. Есть много спец решений БД, параллелилизация, может не очень эффективные решения на триггерах, зато удобные и простые. Ну и как всегда, чем крупнее и богаче бизнес, тем больше есть средств на разработчиков ДБ. Иногда разработчики выполняют некоторые ф-ии DBA, но это не гуд практика
Не оправдываю ХП, но их могут юзать несколько разных сервисов(но это и минус, ибо при изменении может сервис какой-то упасть, если забыть). Для контроля версий БД есть тот же SSDT. Но в целом гибкости никакой с ними.
Правильно сказал. У нас тоже так, на SQL поминимуму хранимок. Проблема действительно оказалась в том что тяжело сопровождать все это потом. Так что удобней на клиенте бизнес-логику хранить.
Могу добавить что когда работаешь с кодом который вот уже 10 лет писали на стороне БД в процедурах и функциях и вдруг компания решает переносить его на сторону клиента получается такая мозаика что голова идет кругом. Да и единообразие кода теряется даже с хорошим планом переноса, в любом случае нужен хороший архитектурный подход в любой реализации кода.
Я запаривался с собственным экстеншном и действительно дизайн прав доступа вызывают определенные трудности. Нужно достаточно много писать служебных UDFок для мониторинга всего этого. Минус не буду ставить, но как и в любой разработке ПО, никто не запрещает тестирование на холодных партициях, хранить код процедур в Гите, деплой аля CI/CD. Нормально не хотеть копаться в кишках БД - это не задача нормального же разработчика. Но хороший код на стороне БД всегда будет быстрее любого кода вне БД. Для меня в ООП самое плохое - объединение данных (атрибутов) с логикой (методами). Но живём же с этим.
А как же резидентные БД? Тобишь, когда значительное количество данных находится в оперативной памяти. В Хане например, логику манипуляции с данными необходимо осуществлять именно на уровне бд, рекомендации от самого sap. Причина в существенном повышении производительности, есть даже SQL Script, который вполне себе полноценный ЯП на котором можно описать сложную логику.
Там где код на стороне данных необходим, вопросов вообще нет. Он необходим, значит пишем. Если есть возможность отделить данные от кода, я предпочитаю это делать. Это личное предпочтение, которое я пытался аргументировать, а там в каждом случае каждому решать самому что как писать код
@@Dev-lessons Ну строго говоря, он там не то чтобы "необходим". Никто не мешает писать его на апликейшн слое, просто работать это будет медленнее. Ничего не имею против разделения, просто вставил свои пять копеек про то что этот подход не везде считается верным.)
Спасибо за видео. Говорят, в банковских ПО использовать ХП-это производственная необходимость, поскольку оперативность превыше всего. Какая статистика использования ХП в банковских программных обеспечениях? Сам не работал в банковской сфере, поэтому не знаю.
Я не знаю, как именно в банках, потому что там не работал. Я в ревордовой системе работал, что почти как банк. Но оперативность некоторых банков говорит о том, что они не торопятся обычно и это правильно, потому что цена ошибки в их коде выше.
@@Dev-lessonsошибиться в коде ООП намного проще, чем в SQL, если конечно код SQL написан правильно. Код SQL намного компактнее и мощнее в задачах обработки данных. А данные - это суть любых бизнес процессов.
Некоторые моменты с которыми я бы поспорил 1. Про обновление процедур в продакшен, это больше критика самого подхода "Хуяк-хуяк в продакшен" чем расширение процедур, их тесты можно и нужно выполнять перед разверткой 2. Создание одного пользователя вместо корректной организации ролей. Есть такая проблема и некоторые этим пренебрегают, но опять же это минус к самой команде, а не к хранению процедур 3. Слой представления это вызов самих процедур и доп абстракции над этими вызовами, это не сами процедуры. "Данные и логика должны жить отдельно", так с процедурами они и живут отдельно и если как вы говорите хотите получать чистые данные, доступ к SQL запросам никто не ограничивает при использовании процедур Остальное не смог досмотреть 9:00
1. Как это решает проблему обновления в продакшн? Под нагрузкой ты без даунтайма не обновишь 2. Согласен, но смысл тогда от процедур, если те, кто их использует на защищается? 3. А сысл тогда в процедурах? Если на БД стороне не будет логики, тогда это чистый SQL.
Потому что они редко пишут код. Они в основном поддерживают программистов, а не разрабатывают что-то. Но у нас на работе БДшники обсуждали такие вопросы и для некоторых удобно всё держать в БД, потому что тогда у них есть возможность оптимизировать, а для других лучше в коде, потому что тогда проще масштабировать и сопровождать.
Пример с преобразованием дат на стороне базы, это всё-таки не про базу, а про понимание как она работает. Можно было изменить запрос под существующие индексы, или построить специальные индексы под такие запросы.
@@Dev-lessons Функциональные индексы я имел в виду. У меня в практике был пример, когда надо было и фильтровать и выдавать агрегированные данные в таймзоне сохранённой в профиле пользователя. И как раз формировать на стороне Постгреса готовый JSON со всеми преобразованиями было быстрее. Как Вы верно заметили про хранимки, это просто инструмент со своими плюсами и минусами, решать пользоваться или нет, надо по ситуации. В том случае оптимальным оказался вариант без хранимок, но с большим и сложным запросом из приложения.
@@IgorGallemar нет, там можно формировать удобные модели данных, разделять логику на простые элементы, отслеживать изменения и почему они сделаны, узнать когда и что было изменено, можно полноценно покрывать код тестами.
@@NecroRomnt бывает, но мне как разработчику проще писать логику на стороне сервера бд и не заморачиваться с перегонкой данных и их обраткой. Хотя отладка процедур это боль для тех чей iq не дотягивает до нужного уровня.
Лежит хомяк, на нем хомяк, хомяк, хомяк - еще хомяк. Это про разработку прям на проде. Как по мне так можно писать представления которые будут держать и выполнять ту самую логику на сторене базы, а так не стоит. Здесь проблема еще в контроле версий такого кода и тестируемости нормальной. :)
Я единственное не понял почему использование хп - это смешивание данных и логики. Данные в виде таблиц лежат "тупыми", а логика рядом в хранимках. То же самое и в коде будет, просто код не на ЯП написан, а на SQL. То же самое разделение.
А что думаешь по поводу файлов.sql в проекте под gitом, которые вызываются с кода как простой sql, просто ну реально же удобно сделать join по 5ти таблицам, всунуть какие нить max и прочие приколюхи, ну и да, преобразования тоже )). Но это смотрится просто и понятно и в одном месте, в коде это размазано и он запутаный и его дохрена )
Это почти то же самое, что хранить SQL в виде констант в cs файле. Просто возьми, переименуй .sql файл в .cs, измени содержимое всего лишь в сохранение в константу твоего SQL и все. Удобство хранения в коде в том, что ты можешь в любой момент перейти на переменную с SQL простым нажатием F12 (в VS). А если ты хранишь в .sql файле, то да, ты хранишь отдельно от кода в одном месте, но оторвано от кода.
@@Dev-lessons ответ то как раз в точку. Нет необходимости изучать? Я эти две штучки терпеть не навижу. Да быстро. Но там столько гемора вылезает и тормозов
Язык ООП и язык структурированных запросов к данных имеют сильно разные парадигмы. Сложные процедуры по обработке данных на SQL можно описать намного компактнее, гибче и мощнее, чем то же самое делать через операции с объектами. Разве это не очевидно? Ежедневный, ежеминутный и прочий регулярный стандартный процессинг - намного правильнее завернуть в хранимую процедуру. И запускать тем же шедулером SQL Server (если о нем речь). Осуждать бизнес логику на стороне SQL Server - стало довольно давно модным. Так давно, что многие даже не вдумываются в суть вопроса, кмк. Но SQL Server - это просто атомный реактор по выполнению бизнес-процессинга, по сравнению с хиленьким дизельком ООП в задачах автоматизации бизнес-процессов. ИМХО, конечно, старовера с 25 летним бг.
@@Dev-lessonsмного раз пытался заставить, вот и сейчас, конечно читал документацию, смотрел код чужих решений. Не могу себя пересилить. Чистый sql мне проще и быстрее.
Но речь не совсем о простых crud операциях. Многие очень сложные нетривиальные процедуры обработки данных на ООП сделать на порядки труднее, чем в stored proc. Они и в ядре сервера, после оптимизации могут занимать часы. А через внешние приложения на EF вообще не уложатся в суточный цикл. Какие нибудь сложные вычисления, статистические расчеты.
Абсолютно верно. С уважением к автору, но возможно он не сталкивался с задачами, которые оптимальнее решить именно на уровне процедур БД. Какая-нибудь последовательная обработка огромного массива (на десятки, а то и сотни миллионов записей), с несколькими последовательными агрегациями, апдейтами, созданиями временных таблиц и т.д. и т.п. А различные сложные аналитические отчеты? В общем, единственно, с чем можно согласиться - что код проще обслуживать, тут с оговорками соглашусь. В остальном - есть логика, которая хорошо ложится и пишется в парадигме ООП/последовательной логики (условно), а есть - которая хорошо ложится и пишется на языке обработки данных. Ну это же разные вещи, зачем их противопоставлять, они скорее должны дополнять друг друга! Для жаркой дискуссии в комментах, если только... ) Рад, что довольно много комментаторов, разумно возражающих. Виден опыт, респект. Не рад, что много комментаторов, еще впитывающих знания, и которым сходу в голову закладывают "модную" тему, что SQL Server - это просто такая коробка для хранения таблиц, а весь огромный ее потенциал для работы с данными - не, ребят, не лезьте туда, вы молодые, шутливые, вам это не надо, вон линк используйте - вам хватит три таблички заджойнить и пару условий накинуть.
Добрый день. Михаил, подскажите реально ли найти работу(опыт 10лет) sql, сейчас изучаю java даже согласен на qa tester через удаленку из Казахстана? И как обстоят у вас рынок работы, если приехать (планирую через год)
Отличное видео! много просматривал это видео и видео про почему не стоит использовать Entity Framework, теперь после многочисленных проб и ошибок, немного начал понимать почему Entity Framework и хранимые процедуры не совсем удобны для разработки ПО
Версионность процедур. Почему бы на пайтоне через миграции alembic создавать/обновлять процедуры? сохранится версионность ???? В алембике есть ветвление. Т.е. как на гитхабе, можно бранч ветки делать и мержить если нужно
Версионность нужна не только для кода локально, но и в работе, чтобы обновлять сервера без даунтайма. У тебя должно быть две версии одновременно, иначе обновление без дауна невозможно
@@Dev-lessonsфайлы миграций пушатся на гит. Разворачивая БД, достаточно запустить одной командой алембик, который прогонит последовательно все миграции. НО это накладывает свои ограничения. Требуется все манипуляции с БД проводить через миграции. Но плюсы: версионность. ветвление UP и DOWN версии В пайтоне алембик стандартный пакет для миграций. Уверен, для других языков есть подобные инструменты.
@@Dev-lessons честно, не знаю что такое "даунтайма". Невнимательно прочитал. Думал возможность отката версии. На новой работе, архитектор БД упорно настаивает использовать хранимые функции. ПРи этом бекенд у меня на пайтоне с БД через ORM. Если что-то он поменяет, вылезет ошибка. Хорошо когда описание ошибки подробное: функция ожидала 20 аргументов, а ты прислал 30, нехорошо. Или ты прислал ХХХ аргумент который не реализован в функции. Тут же ошибка будет "пустой". Пойди разберись быстро, изза чего. и где косяк. В этом неудобство.
@@AlexandrSpirit Отката тоже. Твой вариант будет работать только если использовать trunk based разработку в стиле мусорника. Если использовать feature development, то будут порблемы
Как по мне это вопрос специализации, количества ресурсов проекта и согласованности работы команды. Если "тупые данные", "тупое хранение данных", то сильвупле в NoSQL, но победного шествия этой технологии как бы и нет. А если в команде есть CASTующий волшебник, который умеет работать со схемами и правами и может работать с графовыми базами при расчете себестоимости, то о какой логике на клиенте мы говорим? Если в проекте 1-2 человека и один из них ты, то выполнять проект в стиле и стеке, где ты наиболее уверен в себе это трезвое решение.
@@Dev-lessons ну.... Всё это от обиды.... В конце то концов row или связанные с ним row, превращаются в нужную сущность (структуру) , с которой гораздо проще работать тому, кто знает как с ней работать. А что знает sql о сущности?
Все так ) но немножко не так. Хранить запросы в процедурах полезно, правильно, удобно. Но разработка занимает много времени. Приходит такой говнокодер и дает задание создать хранимку, дба или дбд смотрит на этот код и спрашивают, а собственно что это за говно? Говнокодер его переписывает, и не один раз. Ну понятно что летят все дедлайны, бонусы, кейтеринги. Недоволен говнокодер, недоволен говнотимлид, не доволен говнопм. Ну и кому это надо? Херак херак, и в продакшен, а там пусть дба обьясняет пользователям почему выбор одного контрагента идет 2 минуты и почему из бд тянется вся таблица.
Автор прав, лучше БД воспринимать как тупое хранилище и использовать ее соответствующе. Иногда, конечно, можно констрейнтов навешать, бывает так проще решить какую-то задачу, соблюсти инварианты и т.д. А процедуры в принципе не использую и прекрасно себя чувствую)
Да, процедуры сложно контролировать. Сложно тестировать, разрабатывать, мониторинг медленных запросов усложняется. Бомба замедленного действия на проде) Надо их писать не потому что "смотри чё умею", а исходя из конкретных кейсов. Как говорится "научи дурака молиться"... Можно ещё сайты на ассемблере создавать) но кто их поддерживать будет?)
Процедуры как раз и разрабатвабтся и тестируются чтобы обеспечить максимально производительность и единообразие данных для клиента. А не так чтобы каждый из разработчиков на стороне клиента писал что в голову придёт
@@ДмитрийСтрекалов-т7в а с версионированием как обстоят дела? Как например нам поддерживать одновременно несколько версий процедуры, поднимать несколько баз и при этом думать как бы ещё консистентность не потерять? А на кластере когда база на нескольких серверах как с процедурами?
Я к тому что вы правы, но это для узких кейсов. Логика часто меняется, если продукт развивается, а производительность есть много способов увеличить, через грамотную архитектуру бд, шардирование и секционирование, нормализация или денормализация данных, более мощное железо. Процедуры это последнее что в голову приходит
не работает эта схема - sql в теле программы, уже по той причине, что надо менять схемы таблиц. А там данные. О каких версиях тогда может быть речь? Нет, процедуры на базе СУБД это все таки стандарт и не зря. И вообще избыточные процессы как замена человека - это плохо
Как по договору не знаю. Это же как-то официально должно пройти. Скорей всего банковский перевод (SWIFT). Хотя и Western Union должен работать для официальных вещей. Оба варианта не выгодны с финансовой точки зрения, в лучшем случае дают курс 56 рубля за доллар, хотя он в районе 59-60 рубля
На мой взгляд многовато «воды» получилось. Есть отдельные мысли, которые повторяются на протяжении всего ролика. Рекомендую разбивать свое повествование на тезисы, в каждый тезис вкладывать факты и пример
У меня для этого видео был записан заранее текст, в который я подсматривал, но когда рассказываю на такие спорные темы во время записи постоянно повторяюсь, чтобы лишний раз подчеркнуть определенные вещи. Иначе потом от хейтеров приходится отбиваться.
Не хотите использовать процедуры которые что? Которые собирают и выдают какие-то данные из БД? Так это не бизнес логика, это просто запрос Select которыей перенесен из бэкэнда в функцию на БД. Всё что не изменяет данные на мой взгляд можно смело хранить на БД. Хотя пример с конвертацией даты очень интересен, но это скорее частный случай. Соглашусь с тем, что UPDATE и прочие запросы выполняться в функциях БД не должны. Как пример - есть таблица. В неё добавили дополнительное поле и сразу изменили под это функцию(select). Без манипуляций на бэкэнде фронтэнд получит данные нового поля. Это мега круто. И кстати, что с триггерами? По сути это логика, но создать логику триггера на c# где-то вне БД? Так вообще делают?
Если просто SELECT в процедуре, то зачем, почему нельзя его просто написать без процедуры. Но я видел приложения, где именно рассчеты помещали в процедуры, что на мой взгляд плохо. А если у тебя в бакенде select * , ты добавляешь колонку, без манипуляций на бакенде и фронтенд получает все данные. Функции добавляют проблем в распределенных системах, Посмотри это видео ruclips.net/video/Fs9Tsn40ofs/видео.html Триггеры - это не бизнес логика, обычно это логика целостности данных
Ужас, человек написавший книгу по MS SQL говорит вещи. Хранимки на сервере это гораздо лучше и быстрее чем код на клиенте. Про версионность и обновление совсем загнул, все прекрасно храниться в гите, при деплое на прод попадают все изменения на прод. SQL код ни чем не отличается от кода на любом другом языке программирования. Если построен процесс разработки криво, то не надо искать неправильные технология, надо перестаивать процесс
Вот поэтому я не люблю модел code first . Если уж использовать EF то только в модели DB First . И вообще , я не видел огромные БД , созданные и поддерживаемые в модели code first . Хотя бы потому , что при миллиона клиентов очень критична производительность ... И не видел таких начальников отделов ПО , которые бы согласились отказаться от модели DB First ради того , чтобы всё , абсолютно всё было в ООП . Entity Framework генерирует уже готовые классы данных , которые легко ложаться под многослойку и такая модель даёт возможность избежать создавать в каждой компании свои специфические классы и целые библиотеки , чьё назначение это всего лишь чтение БД . Или даже простая модификация . Это преимущество стандартных (или почти) библиотек от того , что создаёт сам программист и при переходе в другую компанию -- опять должен создавать своё или что чаще -- изучать чужую иерархию классов . Тут гибкий подход должен быть в том , что считать бизнес лэером , а что моделью . Ну а объяснить заказчику почему в продакшене запрещенно что-то менять в процедурах SP и функциях DB это елементарно ибо ниодин заказчик не хочет гемороя , когда всё работало и вдруг с добавлением новой фитчи вдруг начало иногда подвесать ибо что-то в модернизированной (или даже новой) SP не учли и не протестировали (много раз прогнали) на дивелопмент версии .. В больших компания часто SP пишут одни программисты (специ чисто по сиквелу) , а другие пишут клиента , котроллеры на шарпе или на джавке . И очень часто ты приходишь , а том уже 2 тысячи таблиц и полторы тысячи процедур . Поди там объясни как прекрасен ООП ! Если у них один один способ чтения запроса -- ждать пока вся виртуальная таблица подконектится . И что клиент запросил миллион записей - не беда . Пусть мол заказчик больше процессоров ставит и вообще раскошелиться на новое железо . Я начинал работать с БД ещё с MFC ODBC classes . И там вообще не было ДБ Binding и там реально нужен был абстрактный слой , который в одном месте проверяет Count (*) виртуальной таблицы и открывает data source такое колличество сессий , чтобы больше 2х секунд open не подвисал и чтение шло порекордно и передавалось в слой вьюера ассинхронно . Но это когда заказчик крупный холдинг по ПО ... и такая работа с БД -- требование заказчика и есть на то даже спецификация . А вот крайная моя контора -- там начальник спец по SQL Server . И больше ничего толком не понимает (ну кроме его бизнес логики) . 15 лет он эту БД окучивает и его главный критерий : сколь быстро ты пишешь процедуры ...
На мой взгляд автор самоуверенно утверждает что все эти годы что прошли от баз на Paradox до современных версий MS SQL Server, Oracle, DB2 ... ребята тупо ошибались и шли куда то не туда. Ну вперед и флаг тебе в руки. Смело храни свои данные в csv-файлах и рисуй логику на клиенте.
Почитайте Боба Мартина, он как раз пишет что современные СУБД это результат грамотного маркетинга, просто распиарили СУБД, навешали вокруг хранилища данных всякого разного и продали за дорого крупнейшим компаниях.
Есть такая поговорка "если есть проблема с производительностью и решение не лежит на поверхности, то 90% дело в базе". Базы априори нагружены сильнее всех в системе и размещать там ещё и логику не лучшее решение с точки зрения перфоманса.
Спасибо. Поставил для себя точку в вопросе который не давал покоя)
Классное видео. Побольше бы такого контента - про плюсы и минусы того или иного архитектурного выбора.
Уже есть план на следующее видео, что буду рассказывать.
Спасибо за ваше видео, понятно и доступно.
Смог досмотреть, было интересно, согласен во многом.
Работаю в с базами oracle.
Очень тут любят пакеты. И это иногда очень удобно и круто.
Но когда разрабов много. И изменений много. Всего приходится придумывать костыли на нактки дороботок. Тестирования отката.
Про гит вообще боль.
Но иногда через бд решить заду быстрее и дешевле
По поводу гит.
Что мне приходит в голову - хранить процедуры в файликах, и в мёрж реквестах накатывать нужную хранимку хукрм гита.
А ручное накатывания запретить обычным разрабам, через контроль доступа.
Ага видел как это быстро и удобно. Когда перенести изменения с теста (одного из 5) на прод, это тот ещё квест. В то время как с кодом это нажатие одной кнопки. 😂
Недостатком среды разработки SQL server management studio является отсутствие возможности структурировать файлы в виде папок. Все хранимые процедуры в ряд, функции и таблицы тоже. Приходится выходить из положения через использование префиксов в наименованиях. Но все равно потом накапливается много и приходится много листать, что очень не удобно.
Насчёт контроля версий. Код процедур хранится в системных таблицах SQL Server и довольно легко можно автоматизировать журналировние всех изменений в их определениях.
16:57 Так это классика жанра: нам не привыкать решать проблемы, которые мы сами себе и создаём )))
Можно и на стороне приложения такой код нагородить что и сам не разберёшься.
Все есть, и git и unit test и даже ООП в некоторой степени. Использование кода в БД несколько улучшает обстановку с безопасностью, но увеличивает сложность. Бизнес логика часто размазывается между бэком и в БД.
Не все можно сделать или не все удобно делать в ДБ. Если у вас есть хоть какая-то интеграция в приложении (печать, передача файла, импорт, настройки, аутентификация, разные web интеграции и тд и тп) это все по любому будет работать на бэке.
Защита, обработка данных более эффективна и правильна в БД. Есть много спец решений БД, параллелилизация, может не очень эффективные решения на триггерах, зато удобные и простые. Ну и как всегда, чем крупнее и богаче бизнес, тем больше есть средств на разработчиков ДБ. Иногда разработчики выполняют некоторые ф-ии DBA, но это не гуд практика
Не оправдываю ХП, но их могут юзать несколько разных сервисов(но это и минус, ибо при изменении может сервис какой-то упасть, если забыть). Для контроля версий БД есть тот же SSDT. Но в целом гибкости никакой с ними.
Правильно сказал. У нас тоже так, на SQL поминимуму хранимок. Проблема действительно оказалась в том что тяжело сопровождать все это потом. Так что удобней на клиенте бизнес-логику хранить.
Могу добавить что когда работаешь с кодом который вот уже 10 лет писали на стороне БД в процедурах и функциях и вдруг компания решает переносить его на сторону клиента получается такая мозаика что голова идет кругом. Да и единообразие кода теряется даже с хорошим планом переноса, в любом случае нужен хороший архитектурный подход в любой реализации кода.
Не надо переносить логику из БД в клиента.
Я запаривался с собственным экстеншном и действительно дизайн прав доступа вызывают определенные трудности. Нужно достаточно много писать служебных UDFок для мониторинга всего этого.
Минус не буду ставить, но как и в любой разработке ПО, никто не запрещает тестирование на холодных партициях, хранить код процедур в Гите, деплой аля CI/CD. Нормально не хотеть копаться в кишках БД - это не задача нормального же разработчика. Но хороший код на стороне БД всегда будет быстрее любого кода вне БД.
Для меня в ООП самое плохое - объединение данных (атрибутов) с логикой (методами). Но живём же с этим.
А как же резидентные БД? Тобишь, когда значительное количество данных находится в оперативной памяти. В Хане например, логику манипуляции с данными необходимо осуществлять именно на уровне бд, рекомендации от самого sap. Причина в существенном повышении производительности, есть даже SQL Script, который вполне себе полноценный ЯП на котором можно описать сложную логику.
Там где код на стороне данных необходим, вопросов вообще нет. Он необходим, значит пишем. Если есть возможность отделить данные от кода, я предпочитаю это делать. Это личное предпочтение, которое я пытался аргументировать, а там в каждом случае каждому решать самому что как писать код
@@Dev-lessons Ну строго говоря, он там не то чтобы "необходим". Никто не мешает писать его на апликейшн слое, просто работать это будет медленнее. Ничего не имею против разделения, просто вставил свои пять копеек про то что этот подход не везде считается верным.)
Спасибо за видео. Говорят, в банковских ПО использовать ХП-это производственная необходимость, поскольку оперативность превыше всего. Какая статистика использования ХП в банковских программных обеспечениях? Сам не работал в банковской сфере, поэтому не знаю.
Я не знаю, как именно в банках, потому что там не работал. Я в ревордовой системе работал, что почти как банк. Но оперативность некоторых банков говорит о том, что они не торопятся обычно и это правильно, потому что цена ошибки в их коде выше.
@@Dev-lessonsошибиться в коде ООП намного проще, чем в SQL, если конечно код SQL написан правильно. Код SQL намного компактнее и мощнее в задачах обработки данных. А данные - это суть любых бизнес процессов.
@@terabucks Опять же, ты LINQ видел?
"Я не люблю тупо что-то делать, потому что это Тупо!" - цитаты великих людей :)
Как всегда супер контент. Я соглашусь с тем, что код не должен находится на стороне базы данных
Некоторые моменты с которыми я бы поспорил
1. Про обновление процедур в продакшен, это больше критика самого подхода "Хуяк-хуяк в продакшен" чем расширение процедур, их тесты можно и нужно выполнять перед разверткой
2. Создание одного пользователя вместо корректной организации ролей. Есть такая проблема и некоторые этим пренебрегают, но опять же это минус к самой команде, а не к хранению процедур
3. Слой представления это вызов самих процедур и доп абстракции над этими вызовами, это не сами процедуры. "Данные и логика должны жить отдельно", так с процедурами они и живут отдельно и если как вы говорите хотите получать чистые данные, доступ к SQL запросам никто не ограничивает при использовании процедур
Остальное не смог досмотреть 9:00
1. Как это решает проблему обновления в продакшн? Под нагрузкой ты без даунтайма не обновишь
2. Согласен, но смысл тогда от процедур, если те, кто их использует на защищается?
3. А сысл тогда в процедурах? Если на БД стороне не будет логики, тогда это чистый SQL.
Обычно джава разработки любят рассасывать эту тему. Почему разработчики бд не обсуждают нужно ли логику держать в джаве?
Потому что они редко пишут код. Они в основном поддерживают программистов, а не разрабатывают что-то. Но у нас на работе БДшники обсуждали такие вопросы и для некоторых удобно всё держать в БД, потому что тогда у них есть возможность оптимизировать, а для других лучше в коде, потому что тогда проще масштабировать и сопровождать.
Пример с преобразованием дат на стороне базы, это всё-таки не про базу, а про понимание как она работает. Можно было изменить запрос под существующие индексы, или построить специальные индексы под такие запросы.
Как ты построишь специальные индексы? Даже если перестроить запрос под индекс, зачем это нужно, если это не проблема базы данных?
@@Dev-lessons Функциональные индексы я имел в виду.
У меня в практике был пример, когда надо было и фильтровать и выдавать агрегированные данные в таймзоне сохранённой в профиле пользователя.
И как раз формировать на стороне Постгреса готовый JSON со всеми преобразованиями было быстрее.
Как Вы верно заметили про хранимки, это просто инструмент со своими плюсами и минусами, решать пользоваться или нет, надо по ситуации.
В том случае оптимальным оказался вариант без хранимок, но с большим и сложным запросом из приложения.
Не люблю EF. Не люблю хранимые процедуры. Не люблю программировать... буду таксистом. )))))
Логично
Да. Бизнес логика в базе это адская боль. Создаёт весомы сложности в работе с проектом.
Да ладно. С чего боль?
@@IgorGallemar ну не знаю. Мне было сложно отлаживать пол тысячи строк хранимой процедуры, чтобы разобраться с чего это происходит А, а не Б.
@@NecroRomnt да, а эти же 500 строк на стороне приложения тебя не парят?
@@IgorGallemar нет, там можно формировать удобные модели данных, разделять логику на простые элементы, отслеживать изменения и почему они сделаны, узнать когда и что было изменено, можно полноценно покрывать код тестами.
@@NecroRomnt бывает, но мне как разработчику проще писать логику на стороне сервера бд и не заморачиваться с перегонкой данных и их обраткой. Хотя отладка процедур это боль для тех чей iq не дотягивает до нужного уровня.
Спасибо вам!
Лежит хомяк, на нем хомяк, хомяк, хомяк - еще хомяк. Это про разработку прям на проде. Как по мне так можно писать представления которые будут держать и выполнять ту самую логику на сторене базы, а так не стоит. Здесь проблема еще в контроле версий такого кода и тестируемости нормальной. :)
Я единственное не понял почему использование хп - это смешивание данных и логики. Данные в виде таблиц лежат "тупыми", а логика рядом в хранимках. То же самое и в коде будет, просто код не на ЯП написан, а на SQL. То же самое разделение.
Ну если для тебя этого слоя разделения достаточно, то можешь использовать, я же не против.
А что думаешь по поводу файлов.sql в проекте под gitом, которые вызываются с кода как простой sql, просто ну реально же удобно сделать join по 5ти таблицам, всунуть какие нить max и прочие приколюхи, ну и да, преобразования тоже )).
Но это смотрится просто и понятно и в одном месте, в коде это размазано и он запутаный и его дохрена )
Это почти то же самое, что хранить SQL в виде констант в cs файле. Просто возьми, переименуй .sql файл в .cs, измени содержимое всего лишь в сохранение в константу твоего SQL и все. Удобство хранения в коде в том, что ты можешь в любой момент перейти на переменную с SQL простым нажатием F12 (в VS). А если ты хранишь в .sql файле, то да, ты хранишь отдельно от кода в одном месте, но оторвано от кода.
@@Dev-lessons т.е. константа с sql это норм, пусть даже там и присутствует какая нибудь логика?
@@leonardt1798 Если это SQL без хранимых процедур, то ты особо логики туда не поместишь. SELECT - это не логика, это выборка
Знаете, ещё очень интересно услышать ваше мнение про react, vui, для кого они, +, -
Вот в этом я не особо силен, чтобы сравнивать, потому что второго вообще ни разу не видел, только слышал
@@Dev-lessons ответ то как раз в точку. Нет необходимости изучать? Я эти две штучки терпеть не навижу. Да быстро. Но там столько гемора вылезает и тормозов
Язык ООП и язык структурированных запросов к данных имеют сильно разные парадигмы. Сложные процедуры по обработке данных на SQL можно описать намного компактнее, гибче и мощнее, чем то же самое делать через операции с объектами. Разве это не очевидно? Ежедневный, ежеминутный и прочий регулярный стандартный процессинг - намного правильнее завернуть в хранимую процедуру. И запускать тем же шедулером SQL Server (если о нем речь). Осуждать бизнес логику на стороне SQL Server - стало довольно давно модным. Так давно, что многие даже не вдумываются в суть вопроса, кмк. Но SQL Server - это просто атомный реактор по выполнению бизнес-процессинга, по сравнению с хиленьким дизельком ООП в задачах автоматизации бизнес-процессов. ИМХО, конечно, старовера с 25 летним бг.
Ты LINQ в C# использовал?
@@Dev-lessonsмного раз пытался заставить, вот и сейчас, конечно читал документацию, смотрел код чужих решений. Не могу себя пересилить. Чистый sql мне проще и быстрее.
Но речь не совсем о простых crud операциях. Многие очень сложные нетривиальные процедуры обработки данных на ООП сделать на порядки труднее, чем в stored proc. Они и в ядре сервера, после оптимизации могут занимать часы. А через внешние приложения на EF вообще не уложатся в суточный цикл. Какие нибудь сложные вычисления, статистические расчеты.
Не мешай хомячкам жувать кактус))
Абсолютно верно. С уважением к автору, но возможно он не сталкивался с задачами, которые оптимальнее решить именно на уровне процедур БД. Какая-нибудь последовательная обработка огромного массива (на десятки, а то и сотни миллионов записей), с несколькими последовательными агрегациями, апдейтами, созданиями временных таблиц и т.д. и т.п. А различные сложные аналитические отчеты?
В общем, единственно, с чем можно согласиться - что код проще обслуживать, тут с оговорками соглашусь. В остальном - есть логика, которая хорошо ложится и пишется в парадигме ООП/последовательной логики (условно), а есть - которая хорошо ложится и пишется на языке обработки данных. Ну это же разные вещи, зачем их противопоставлять, они скорее должны дополнять друг друга! Для жаркой дискуссии в комментах, если только... )
Рад, что довольно много комментаторов, разумно возражающих. Виден опыт, респект.
Не рад, что много комментаторов, еще впитывающих знания, и которым сходу в голову закладывают "модную" тему, что SQL Server - это просто такая коробка для хранения таблиц, а весь огромный ее потенциал для работы с данными - не, ребят, не лезьте туда, вы молодые, шутливые, вам это не надо, вон линк используйте - вам хватит три таблички заджойнить и пару условий накинуть.
Добрый день. Михаил, подскажите реально ли найти работу(опыт 10лет) sql, сейчас изучаю java даже согласен на qa tester через удаленку из Казахстана? И как обстоят у вас рынок работы, если приехать (планирую через год)
Не знаю, как сейчас, когда я подавался, со мной не разговаривали, пока я не приехал в Канаду.
@@Dev-lessons а вообще если приехать, как обстоят дела с ит профессией? Как думаете насчет Калгари?
@@bekbek2660В Калгари очень красиво. Но с точки зрения работы там хуже, чем в Онтарио.
ruclips.net/video/sh-ljv2jt78/видео.html
@@Dev-lessons спасибо. Когда у вас прямые эфиры будут?
@@bekbek2660 Не знаю, пока не планировал
Отличное видео! много просматривал это видео и видео про почему не стоит использовать Entity Framework, теперь после многочисленных проб и ошибок, немного начал понимать почему Entity Framework и хранимые процедуры не совсем удобны для разработки ПО
Теперь понятно почему среднего уровня конторы очень хотят джунов, которые понимают процедууры и пр магию на стороне базы)
Версионность процедур. Почему бы на пайтоне через миграции alembic создавать/обновлять процедуры? сохранится версионность ????
В алембике есть ветвление. Т.е. как на гитхабе, можно бранч ветки делать и мержить если нужно
Версионность нужна не только для кода локально, но и в работе, чтобы обновлять сервера без даунтайма. У тебя должно быть две версии одновременно, иначе обновление без дауна невозможно
@@Dev-lessonsфайлы миграций пушатся на гит.
Разворачивая БД, достаточно запустить одной командой алембик, который прогонит последовательно все миграции.
НО это накладывает свои ограничения. Требуется все манипуляции с БД проводить через миграции.
Но плюсы:
версионность.
ветвление
UP и DOWN версии
В пайтоне алембик стандартный пакет для миграций. Уверен, для других языков есть подобные инструменты.
@@AlexandrSpiritА обновлять БД без даунтайма как?
@@Dev-lessons честно, не знаю что такое "даунтайма". Невнимательно прочитал. Думал возможность отката версии.
На новой работе, архитектор БД упорно настаивает использовать хранимые функции. ПРи этом бекенд у меня на пайтоне с БД через ORM. Если что-то он поменяет, вылезет ошибка. Хорошо когда описание ошибки подробное: функция ожидала 20 аргументов, а ты прислал 30, нехорошо. Или ты прислал ХХХ аргумент который не реализован в функции.
Тут же ошибка будет "пустой". Пойди разберись быстро, изза чего. и где косяк.
В этом неудобство.
@@AlexandrSpirit Отката тоже. Твой вариант будет работать только если использовать trunk based разработку в стиле мусорника. Если использовать feature development, то будут порблемы
Как по мне это вопрос специализации, количества ресурсов проекта и согласованности работы команды. Если "тупые данные", "тупое хранение данных", то сильвупле в NoSQL, но победного шествия этой технологии как бы и нет. А если в команде есть CASTующий волшебник, который умеет работать со схемами и правами и может работать с графовыми базами при расчете себестоимости, то о какой логике на клиенте мы говорим? Если в проекте 1-2 человека и один из них ты, то выполнять проект в стиле и стеке, где ты наиболее уверен в себе это трезвое решение.
Это вопрос архитектуры. В рамках микросервисной архитектуры не имеет смысл держать логику в БД. Т.к. смысл, что приложение должно падать. 😂
@@erlanibraev Сколько у Вас успешных проектов?
@@AnonAristotel С 10-к минимум. 😂
@@erlanibraev и все 10 падают?
@@AnonAristotel В зависимости от архитектуры. 😉
Разве надо "знать " больше чем, select, update, insert и delete, для хранения данных и использования данных?
В том то и дело, что я считаю, что достаточно. Но на этом же SQL не заканчивается и T-SQL добавляет курсоры, циклы, условные операторы...
@@Dev-lessons ну.... Всё это от обиды.... В конце то концов row или связанные с ним row, превращаются в нужную сущность (структуру) , с которой гораздо проще работать тому, кто знает как с ней работать. А что знает sql о сущности?
Нет, для простого "блокнотика" достаточно, а для серьезных проектов, это 1% от нужного знания, чтобы писать эффективный процедурный код!
Все так ) но немножко не так. Хранить запросы в процедурах полезно, правильно, удобно. Но разработка занимает много времени. Приходит такой говнокодер и дает задание создать хранимку, дба или дбд смотрит на этот код и спрашивают, а собственно что это за говно? Говнокодер его переписывает, и не один раз. Ну понятно что летят все дедлайны, бонусы, кейтеринги. Недоволен говнокодер, недоволен говнотимлид, не доволен говнопм. Ну и кому это надо? Херак херак, и в продакшен, а там пусть дба обьясняет пользователям почему выбор одного контрагента идет 2 минуты и почему из бд тянется вся таблица.
На на бакендовых языках тоже часто говнокодят и тоже синьоры иногда заставляют переписывать.
Автор прав, лучше БД воспринимать как тупое хранилище и использовать ее соответствующе. Иногда, конечно, можно констрейнтов навешать, бывает так проще решить какую-то задачу, соблюсти инварианты и т.д. А процедуры в принципе не использую и прекрасно себя чувствую)
Да, процедуры сложно контролировать. Сложно тестировать, разрабатывать, мониторинг медленных запросов усложняется. Бомба замедленного действия на проде)
Надо их писать не потому что "смотри чё умею", а исходя из конкретных кейсов. Как говорится "научи дурака молиться"... Можно ещё сайты на ассемблере создавать) но кто их поддерживать будет?)
Процедуры как раз и разрабатвабтся и тестируются чтобы обеспечить максимально производительность и единообразие данных для клиента. А не так чтобы каждый из разработчиков на стороне клиента писал что в голову придёт
@@ДмитрийСтрекалов-т7в а с версионированием как обстоят дела? Как например нам поддерживать одновременно несколько версий процедуры, поднимать несколько баз и при этом думать как бы ещё консистентность не потерять? А на кластере когда база на нескольких серверах как с процедурами?
@@ДмитрийСтрекалов-т7в аб-тестирование например хотим провести. Легче это сделать когда это логика в коде сервиса, чем в самой базе
Я к тому что вы правы, но это для узких кейсов. Логика часто меняется, если продукт развивается, а производительность есть много способов увеличить, через грамотную архитектуру бд, шардирование и секционирование, нормализация или денормализация данных, более мощное железо. Процедуры это последнее что в голову приходит
Не смотрел, но осуждаю. У Михаила довольно своеобразный взгляд на ХП
Осуждай, я не против. Это выбор каждого - использовать или нет
не работает эта схема - sql в теле программы, уже по той причине, что надо менять схемы таблиц. А там данные. О каких версиях тогда может быть речь? Нет, процедуры на базе СУБД это все таки стандарт и не зря. И вообще избыточные процессы как замена человека - это плохо
Номер стандарта или хоть ссылку какую-то можно на любой документ со словом стандарт, где сказано, что нужно использовать процедуры?
Я только не понял, почему логика в C#, а не в Go? 🤣🤣
Хороший вопрос программисту, который пишет в основном на C# :) потому что я предвзятый к тому, что люблю.
@@Dev-lessons я вот тоже, поэтому и не понимаю 🤣🤣🤣
Даже взять футболку, с гофером нереально крутая! А что интересного в футболке с C#?
Нужно из России в Канаду отправить 25зел
По договору купли продажи.
Подскажите пожалуйста как это сделать
Как по договору не знаю. Это же как-то официально должно пройти. Скорей всего банковский перевод (SWIFT). Хотя и Western Union должен работать для официальных вещей. Оба варианта не выгодны с финансовой точки зрения, в лучшем случае дают курс 56 рубля за доллар, хотя он в районе 59-60 рубля
На мой взгляд многовато «воды» получилось. Есть отдельные мысли, которые повторяются на протяжении всего ролика.
Рекомендую разбивать свое повествование на тезисы, в каждый тезис вкладывать факты и пример
У меня для этого видео был записан заранее текст, в который я подсматривал, но когда рассказываю на такие спорные темы во время записи постоянно повторяюсь, чтобы лишний раз подчеркнуть определенные вещи. Иначе потом от хейтеров приходится отбиваться.
Не хотите использовать процедуры которые что? Которые собирают и выдают какие-то данные из БД? Так это не бизнес логика, это просто запрос Select которыей перенесен из бэкэнда в функцию на БД. Всё что не изменяет данные на мой взгляд можно смело хранить на БД. Хотя пример с конвертацией даты очень интересен, но это скорее частный случай. Соглашусь с тем, что UPDATE и прочие запросы выполняться в функциях БД не должны.
Как пример - есть таблица. В неё добавили дополнительное поле и сразу изменили под это функцию(select). Без манипуляций на бэкэнде фронтэнд получит данные нового поля. Это мега круто.
И кстати, что с триггерами? По сути это логика, но создать логику триггера на c# где-то вне БД? Так вообще делают?
Если просто SELECT в процедуре, то зачем, почему нельзя его просто написать без процедуры. Но я видел приложения, где именно рассчеты помещали в процедуры, что на мой взгляд плохо.
А если у тебя в бакенде select * , ты добавляешь колонку, без манипуляций на бакенде и фронтенд получает все данные. Функции добавляют проблем в распределенных системах, Посмотри это видео ruclips.net/video/Fs9Tsn40ofs/видео.html
Триггеры - это не бизнес логика, обычно это логика целостности данных
Ужас, человек написавший книгу по MS SQL говорит вещи. Хранимки на сервере это гораздо лучше и быстрее чем код на клиенте. Про версионность и обновление совсем загнул, все прекрасно храниться в гите, при деплое на прод попадают все изменения на прод. SQL код ни чем не отличается от кода на любом другом языке программирования. Если построен процесс разработки криво, то не надо искать неправильные технология, надо перестаивать процесс
Согласен. Ужас ужасный
Вот поэтому я не люблю модел code first . Если уж использовать EF то только в модели DB First .
И вообще , я не видел огромные БД , созданные и поддерживаемые в модели code first .
Хотя бы потому , что при миллиона клиентов очень критична производительность ... И не видел таких начальников отделов ПО , которые бы согласились отказаться от модели DB First ради того , чтобы всё , абсолютно всё было в ООП .
Entity Framework генерирует уже готовые классы данных , которые легко ложаться под многослойку и такая модель даёт возможность избежать создавать в каждой компании свои специфические классы и целые библиотеки , чьё назначение это всего лишь чтение БД .
Или даже простая модификация . Это преимущество стандартных (или почти) библиотек от того , что создаёт сам программист и при переходе в другую компанию -- опять должен создавать своё или что чаще -- изучать чужую иерархию классов .
Тут гибкий подход должен быть в том , что считать бизнес лэером , а что моделью .
Ну а объяснить заказчику почему в продакшене запрещенно что-то менять в процедурах SP и функциях DB это елементарно ибо ниодин заказчик не хочет гемороя , когда всё работало и вдруг с добавлением новой фитчи вдруг начало иногда подвесать ибо что-то в модернизированной (или даже новой) SP не учли и не протестировали (много раз прогнали) на дивелопмент версии ..
В больших компания часто SP пишут одни программисты (специ чисто по сиквелу) , а другие пишут клиента , котроллеры на шарпе или на джавке . И очень часто ты приходишь , а том уже 2 тысячи таблиц и полторы тысячи процедур . Поди там объясни как прекрасен ООП !
Если у них один один способ чтения запроса -- ждать пока вся виртуальная таблица подконектится . И что клиент запросил миллион записей - не беда . Пусть мол заказчик больше процессоров ставит и вообще раскошелиться на новое железо .
Я начинал работать с БД ещё с MFC ODBC classes . И там вообще не было ДБ Binding и там реально нужен был абстрактный слой , который в одном месте проверяет Count (*) виртуальной таблицы и открывает data source такое колличество сессий , чтобы больше 2х секунд open не подвисал и чтение шло порекордно и передавалось в слой вьюера ассинхронно . Но это когда заказчик крупный холдинг по ПО ... и такая работа с БД -- требование заказчика и есть на то даже спецификация .
А вот крайная моя контора -- там начальник спец по SQL Server . И больше ничего толком не понимает (ну кроме его бизнес логики) . 15 лет он эту БД окучивает и его главный критерий : сколь быстро ты пишешь процедуры ...
С EF теряешь контроль и теряешь в производительности
На мой взгляд автор самоуверенно утверждает что все эти годы что прошли от баз на Paradox до современных версий MS SQL Server, Oracle, DB2 ... ребята тупо ошибались и шли куда то не туда. Ну вперед и флаг тебе в руки. Смело храни свои данные в csv-файлах и рисуй логику на клиенте.
Я просто рассказал, почему я не использую. Вообще ничего не утверждаю.
Почитайте Боба Мартина, он как раз пишет что современные СУБД это результат грамотного маркетинга, просто распиарили СУБД, навешали вокруг хранилища данных всякого разного и продали за дорого крупнейшим компаниях.
Первый!)))
Повезло, обогнал, я с плохой связью сижу
Есть такая поговорка "если есть проблема с производительностью и решение не лежит на поверхности, то 90% дело в базе". Базы априори нагружены сильнее всех в системе и размещать там ещё и логику не лучшее решение с точки зрения перфоманса.