Комментарии 23
Кто в энетерпрайзе работал, тот в цирке не смеётся.
Толпа умных людей, это в первую очередь толпа. ИТ-шный "энтерпрайз" - один из вариантов толпы. Все умные, высокооплачиваемые, все всё понимают, но на выходе получается хрень из-за постоянной несогласованности.
С другой стороны, в этом есть плюс - в отдельных случаях можно конкурировать с гигантами своим небольшим решением.
хороший пример показывающий зачем нужна буковка "Р" в аббревеатуре РСУБД.
Ну и докучи, что без тестов жить плохо, а с тестами хорошо
Жиза, что тут скажешь. Вспоминаю взаимодействие по обмену данными с Пенсионным фондом в позапрошлой жизни... О! Когда люди мамой клянутся, что СНИЛС - уникальный идентификатор человека и дубли невозможны по определению. Ок, делаю СНИЛС первичным ключом и... и... при первой же загрузке данных от них получаем нарушение уникальности. Начинаем выяснять, в чем дело: а, ну да, вот в таком-то случае СНИЛС может повторяться (!!!). Но это очень-очень редко, у нас на область всего три таких случая, а так СНИЛС уникален!
Да какая мне разница, 3 или 3333, надо срочно менять первичный ключ, учитывать это все, а начальство стоит буквально за спиной и ему глубоко пофигу твои объяснения, ты срываешь обмен данными и все тут.
С тех пор я стал убежденным сторонником синтетических первичных ключей.
Примечание. Прошло 20 лет или даже больше, сейчас уже не вспомню, в какой там ситуации было возможно нарушение уникальности СНИЛС, возможно, это давно исправлено.
Независимо от уникальности есть ещё такая штука как ошибка ввода. И изменение законов. И хранение в БД удалённых значений. И ошибка постановки задачи. В-общем, да, синтетические ключи рулят.
такая штука как ошибка ввода. И изменение законов. И хранение в БД удалённых значений
вот чтобы их не было и ставят constraints
вот чтобы их не было и ставят constraints
Предположем я по ошибке добавил ваш номер. Сonstraints не ругаются.
Терерь вы пробуете ввести свой номер. Сonstraints вам этого сделать не дадут.
Переименование первичного ключа, это не та фича которая идёт в большинстве сервисов из коробки. А если есть интеграции с внешними системами и ключ расползся по другим базам, то будет совсем весело.
В случае нарушения процедуры его выпуска. И да, все врут. И эксперты заказчика, и назначенные на проект аналитики, а тем более пользователи (и ваше начальство).
Возможно, ситуация не была бы такой серьёзной, если бы вы генерировали ключ на основе СНИЛС, а не использовали его впрямую.
Однако проблема не является уникальной, и, я думаю, есть много мест, где воткнуть костыли, чтобы обойти эту проблему.
Я сталкивался с тем что у человека поменяли ИНН (физика). Хотя это в принципе не предусмотрено никакими процедурами, в т.ч. законом
Датахорор вроде xD
Как я случайно сэкономил компании полмиллиона долларов: https://habr.com/ru/companies/ncloudtech/articles/783564/
Клёво. Хотел бы я там поработать, будучи нанятым для автоматизации всего этого. Особенно если платят волшебно.
Есть идеи, как идентифицировать конкретные запуски, если не предполагать, что выполнялся только один запуск за день?
Там вся система на .txt. Date created/date modified.
Вообще, я, может, узко мыслю, но подгрузить JSON скопом из каталога/s3 в Greenplum или Trino - задача тривиальная. Валидность за каждый день проверяется простым SELECT, если облом - данные битые. Ну и выборка по колонкам отсекла бы историю с Google-аналитикой.
Валидность за каждый день проверяется простым SELECT, если облом - данные битые.
Давно это было. В соседней комнате работали с системой, где принимают данные о школьных оценках.
Схема есть, но версионирования нет. В школах обновление в ручною, то есть с дестяток разных версий программы шлут данные в одино и тоже место.
Новые схемы выходят без предупреждения. И узнаешь ты об этом, когда их начинают слать.
По контракту ты должен их принять, чтобы не попасть на штрафы.
Это я к тому, что "проверяется простым SELECT" в грязных данных не работает.
Клёво. Хотел бы я там поработать, будучи нанятым для автоматизации всего этого. Особенно если платят волшебно.
Вся статья это пример, что в таких конторах можно вообще на работать и только ходить на митинги. Часто проекты там чтобы освоить бюджет или показать кипучую деятельность и перед релизом свалить на повышение. Мотивации сделать хорошо нет.
В таких конторах можно работать, когда не хочешь развиваться дальше.
Странная статья ни о чем. Ну не нравится - так поменяй. И необязательно переписывать сразу все и идеально, меняй кусочками - да хоть формат лога от разных модулей. И даталейки не нравятся - ну танцуй по ночам, когда будет ломаться очередная загрузка в двх. Или еще лучше, откажемся от централизованных хранилищ и будем прод ломать или работать сразу на 100-150 базах данных (у нас же микросервисы нынче).
Удачного ему консалтинга, но долго он так не проживет.
Странная статья ни о чем. Ну не нравится - так поменяй.
Это не его сервис, он с ними интегрируется. Далеко не везде можно вот так прийти и поменять чужой сервис.
концепция "не нравится - так поменяй" - она хорошая, без дураков, но вот вопрос: долго ли вы так сможете чисто на собственном энтузиазме, без поставленной сверху задачи и, фактически, на морально-волевых? Учитываем, что за улучшайзинг, естественно, вам отдельно никто не доплачивает, конечно, все в рамках собственных инициатив. И да, биться головой в стены и образать людей в свою веру тестирования, проверки данных и т.д. - это довольно выматывающе, все-таки ( На первых порах оно даже может драйвить, но вот потом, если отдачи никакой нет, - только эмоциональный спад. Так и живем.
В одном месте работы было порядка 3000 скриптов, которые переносили данные, к окончанию работы удалось свести их к 6 разновидностям, оформить в виде сервисов (с автоматическим масштабированием и восстановлением работы при сбоях), а пайплайны сделать в виде блок-схемы которую может нарисовать и менеджер. Все в руках сотрудников, было бы желание.
Спасите меня из ада данных