KopilogusПоделитесь опытом, кто каким образом ограничивает пользователей БД от написания плохого t-sql кода?

На вскидку, есть простые очевидные рекомендации , но к сожалению разработчики их не всегда соблюдаютЭэээ, как можно сделать это автоматически? :-)

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

Всякие анализаторы кода помогут в настолько малом числе случаев, что ИМХО их применение будет сильно вредить, успокаивая "всё хорошо".

Квалифицированный специалист увидит, что человек пишет кривой код, и его не нужно брать с испытательного срока. И он должен этим управлять, даже если вы напишете триггер ,который ругнётся (в 5% случаев) на кривой код и не даст его вставить.

Т.е., затраты на "анализатор" будут, а прибыли в компанию с этих затрат - нет. Так какой смысл?
KopilogusК примеру - нельзя создать процедуру в которой используется ORDER BY, GROUP BY Ээээ, как можно не делать ORDER BY ,если в задании написано "сделать ORDER BY"? Или вы про то, что делают ORDER BY тогда, когда этого не надо? Тогда способ борьбы описан выше.

alexeyvgKopilogusПоделитесь опытом, кто каким образом ограничивает пользователей БД от написания плохого t-sql кода?

На вскидку, есть простые очевидные рекомендации , но к сожалению разработчики их не всегда соблюдаютЭэээ, как можно сделать это автоматически? :-)

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

Всякие анализаторы кода помогут в настолько малом числе случаев, что ИМХО их применение будет сильно вредить, успокаивая "всё хорошо".

Квалифицированный специалист увидит, что человек пишет кривой код, и его не нужно брать с испытательного срока. И он должен этим управлять, даже если вы напишете триггер ,который ругнётся (в 5% случаев) на кривой код и не даст его вставить.

Т.е., затраты на "анализатор" будут, а прибыли в компанию с этих затрат - нет. Так какой смысл?
KopilogusК примеру - нельзя создать процедуру в которой используется ORDER BY, GROUP BY Ээээ, как можно не делать ORDER BY ,если в задании написано "сделать ORDER BY"? Или вы про то, что делают ORDER BY тогда, когда этого не надо? Тогда способ борьбы описан выше.Добавлю, что если уж заговорили о технических средствах избавления от говнокода, то начать нужно с:
- средств разработки,
- хранения исходников в базе версионного контроля,
- привязки изменений к требованиям,
- тестировании,
- автоматических ночных сборках,
- деплоях,
- работать с цепочкой разработка - стабильный тест - продакшен.
и т.п.

А то народ зачастую правит код в продакшене прямо внутри базы (практически как в экзешнике в кодах), и потом рассуждает, как избавиться от говнокода :-)

Yasha123вы в состоянии всю эту логику запихнуть в политику?
это ж прям парсер надо свой писать,
причем офигительный такой парсер...И, главное, этим не убрать остальные 90% мест, где можно наговнокодить. Это же только некоторые простые правила.
То есть это не избавит от необходимости читать код, учить, увольнять и т.д. А при контроле "глазами" все перечисленные ляпы будет видно моментально, так зачем делать этот анализатор?

КритикalexeyvgЭэээ, как можно сделать это автоматически? :-)

в студии можно,
если проверок не хватает - можно написать свою, в инете есть примерыЯ писал про другое. Такое да, можно, и есть много средств для этого.

invmKopilogusесть простые очевидные рекомендации Да уж...
Редкостный бред.Ладно, многие из них выглядят вполне разумно. Только если без формализма, и понимая, "почему".
Вот ещё есть, пошире списочек: https://www.dbrnd.com/2016/12/database-design-common-practices-for-database-developers-and-application-developers/

Но смысл предложения ТС в другом - можно нанять плохих разработчиков, уволить хороших, настроить средство автоматического запрета говнокода, и получить профит.
Так вот, идея неудачная. Не получиться так сделать.

invmalexeyvgЛадно, многие из них выглядят вполне разумно.Выглядят может и разумно, только не для оптимизации производительности.
А в причинах описаны, в большинстве, чьи-то фантазии.Вообще да, неквалифицированность автора прямо выпирает, если приглядеться :-)
Что то разумно, да, но в целом, как будто автор совсем начинающий.

Впрочем, понятно, если посмотреть на профиль - опытный программист, с неслабым самомнением, но совсем не специалист по MSSQL, высказывает о нём своё мнение, пишет "правила" (!). Я встречал таких, бывало.