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, высказывает о нём своё мнение, пишет "правила" (!). Я встречал таких, бывало.

Гулин Федорalexeyvgпропущено...

Вот ещё есть, пошире списочек: https://www.dbrnd.com/2016/12/database-design-common-practices-for-database-developers-and-application-developers/


Use Natural Primary key rather than Surrogate Primary key . Natural Primary keys are keys base on an external meaningful data. Surrogate Primary key are keys base on an auto-increment number or values which have no meaning outside the system

хм всегда считал ровно Наоборот (конечно есть исключения )Есть 2 вида проектировщиков баз данных. Одни ...
:-)

Alexander UsКритикAlexander Us,

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

Не воспринимайте буквально.
Я имел ввиду, что элементарную квалификацию пользователей и организацию работы не заменить сводои догм.Понятно, что, эти 50 штук разработчиков будут разбираться в ограничениях как в "чёрном ящике"?
- "Вот так написали, не прокатило, ошибка. Попробуем так... А вообще, для какого сервера БД мы пишем, где про него можно прочитать?"
Понятно, что нужно какое то описание, + квалификация, + старшие (а то один специалист на 50+ неучей выглядит странно, он с некоторыми может даже за год не поговорить не разу).

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

Впрочем, понятно, если посмотреть на профиль - опытный программист, с неслабым самомнением, но совсем не специалист по MSSQL, высказывает о нём своё мнение, пишет "правила" (!). Я встречал таких, бывало.
авторI have more than six years of experience with various RDBMS products like MSSQL Server, PostgreSQL, MySQL, Greenplum and currently learning and doing research on BIGData and NoSQL technologyЭто наверное по 1 году на каждую технологию. Очень опытный эксперт. С сертификатом от Oracle без знания Oracle...Я писал про автора первых "рекомендаций", Nikhil Devre. "I work as a Senior Application Architect."

Второй, ANVESH PATEL, про которого вы пишите, всё таки специалист по БД.

Критикalexeyvgпропущено...
Понятно, что, эти 50 штук разработчиков будут разбираться в ограничениях как в "чёрном ящике"?
- "Вот так написали, не прокатило, ошибка. Попробуем так... А вообще, для какого сервера БД мы пишем, где про него можно прочитать?"
Понятно, что нужно какое то описание, + квалификация, + старшие (а то один специалист на 50+ неучей выглядит странно, он с некоторыми может даже за год не поговорить не разу).

инструкции у нас есть, но их читают только неудачники (а может просто трудно сразу запомнить сотни страниц описаний), а так раз выскочила ошибка - и сразу с описанием, что сделано неправильноВот, в этом и проблема - инструкций нет (раз их никто не читает), желания (или денег) на вменяемые инструкции и вменяемое управление нет, масса бесполезных (но самых высокооплачиваемых) людей (которые должны были бы управлять и писать) радостно пилят деньги вместо работы, ну а с разработчиков, нанятых по остаточному принципу, чего спрашивать? поют как умеют.

Сон Веры ПавловныГигабайт Мегабайтович Килобайтов таки в вашем случае напрашивается ревью кода разработчиками, а после админами
Ревью кода админами - это вообще одна из самых странных вещей, про которые мне приходилось слышать. Такое где-то бывает? Может, там админов перевести в разработчики, и вся недолга?Как сказать, конечно, если человек делает ревью, то есть "разрабатывает", то он "разработчик", но иногда такие люди называются DBA, и это общемировая практика.
Т.е. бывает, часть обязанностей DBA - разрабатывать код для СУБД (более сложный, чем простые селекты, и более нестандартный, чем отчётные процедуры), попутно консультировать разработчиков, ну и делать ревью их кода.
Не всегда так, но есть, можно посмотреть описание вакансий на зарубежных сайтах.

Критика код-ревью - это почти х2 трудозатрат на разработку, мало мест, где такое согласуют, ведь все должно быть реализовано еще вчераПарное программирование - это "почти х2 трудозатрат", и действительно редко встречается, а ревью как раз стоит немного.
Я не работал за много лет ни в одном месте, где бы оно не делалось (хотя видел такое).
Что бы кто то опытный, или начальник, никогда не взглянул на код джуниора, или не поправил бяки, если всё равно делает модификацию этого кода? Это надо очень сильно накласть на качество кода, продукта, профессию, самоуважение, и всё такое :-)

Критикalexeyvg,

Все завист от того, что вы понимаете под ревью, если глянуть правильность наименований объектов, то это быстро, а если смотреть логику процедуры из нескольких тысяч строк, то может получиться и больше, чем х2Мы говорили про "автоматический контроль на простокод"?

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

И вы так же не сможете автоматически проверить вменяемость кода как такового, кроме некоторых простых правил, а вот взглядом специалиста это как раз проверяется просто. Ещё раз подчеркну, что автоматическая проверка даст ложное чувство защищённости.

Затраты на ревью и контроль можно регулировать, понятно, что если это условно "ракета", то контроля может быть много, а если это обычный рядовой код от джуниора, то проверка на "вменяемость" не займёт много времени, к тому же реально её достаточно делать выборочно, и покажет она несравнимо больше автоматического контроля.

daoно основное - правильность написания sql-кода, и вот тут очень помогает регламент+1
Только он должен быть правильный, а не "просто трудно сразу запомнить сотни страниц описаний"

Например, разработчики обычно берут пример и переделывают, вместо того, что бы писать с нуля. Так сделайте шаблоны, + отмечайте "эталонные" процедуры (и другой код) каким то образом.

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

То есть, собственно, тут тонкость в том, что, оказывается, руководители, аналитики, архитекторы тоже могут быть квалифицированными и тоже могут участвовать в проекте! Представляете? А не просто где то "быть", то есть вроде они есть, но непонятно что это такое, ну и при большом желании можно нарыть папочки, куда наваливаются кучки файликов с никому не нужными результатами их жизнедеятельности.