Гулин Федор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 трудозатрат", и действительно редко встречается, а ревью как раз стоит немного.
Я не работал за много лет ни в одном месте, где бы оно не делалось (хотя видел такое).
Что бы кто то опытный, или начальник, никогда не взглянул на код джуниора, или не поправил бяки, если всё равно делает модификацию этого кода? Это надо очень сильно накласть на качество кода, продукта, профессию, самоуважение, и всё такое :-)