Всем привет! Подскажите пожалуйста, стоит ли во все таблицы добавлять

created_at и updated_at? Или это бесполезно?

добавляют куда нужно и когда нужно

если это технические или статические данные - то нафига?

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

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

Мне не нужен аудит

а чем тогда выручает?

Ну всякое случается. Бывает баг посадили и нужно потенциально проблемные данные достать. Бывает бизнем что-нибудь прлсит посчитать быренько. Если потребуется версилнирование, то created и updated могут пригодитбся для инициалищации. Да и потом, сегодня бизнесу ненужно - а завтра нужно

Ну такое

Это оценочное суждение, мне совсем не ценно. Человек попросил поросил поделиться мнением, я не просил делиться мнением. Если решаете свои проблемы через аудит, то ок. А я все равно буду добавлять created и updated, потому что это почти бесплатно, а пользы может много принести

1. Про баг - камон, логи 2. Что то посчитать быстренько - вроде себе бизнес, ну вот для бизнеса и добавляешь 3. Про версионирование - хз как оно тебе поможет 4. Вот когда нужно бизнесу, тогда и добавляешь)))

Т.е. ты руками заполняешь эти поля?)

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

Нет, настройками базы

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

Ни при каких случаях? Тип, есть один единственно верный подход и ты его будешь придерживаться в любой ситуации?

А если это мусорка с данныму, куда аналитики ходят руками? И иногда руками обновляют что-то. А если в эту базу ходит более одного сервиса? А если ходит ЕТЛ и помечает обработанные поля? А если есть требование перейти на другой фреймворк по работе с бд?

1. Ходят руками что то правят - это пиздец как неправильно, за изменение данных должно отвечать только приложение 2. Одна база - один сервис, если в одну базу ходит более одного сервиса - это тоже пиздец как неправильно 3. Какого хера у etl не своя база?))) 4. Берешь и переходишь на другой фреймворк) а если надо базу поменять?) Ты собрал в одном сообщении большинство типовых антипаттернов разработки😂

насчёт 2 пункта таки спорно - из одной базы могут читать данные несколько сервисов

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

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

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

Изменение данных боевой базы руками очень чревато)))

зависит от ситуации

Ну вот оно нифига и не всегда так

У нас всегда запрет. Делается фикс и патч

ураа, рад за вас но в других командах, возможно, это реализовано по другому

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

Даже звучит как жесть если честно)