Andrey Strelnikov wrote: 29 Dec 2021 14:56
А вообще ID типа integer (и к тому же инкрементные) удобны только в начале жизненного цикла приложения. Относительно простого.
А почему это? И что не так с инкрементными ID типа integer?
Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.
Andrey Strelnikov wrote: 29 Dec 2021 18:07
Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.
а как потом какой-нить дата инженер из кафки или из спарка данные будет заливать ? он должен будет свой мутный алгоритм генерации выдумывать или обязан будет пройти квест с поиском того кто такое выдумал?
Andrey Strelnikov wrote: 29 Dec 2021 18:07
Ну вот версии у вас появятся. Поле отдельное прийдется таскать всюду.
Длины поля скорее всего хватит на жизнь приложения - но тоже потенциальная опасность.
Или вдруг прийдется на несколько серверов БД жить. Или просто сливать в централизованную БД. Уже немасштабируемо просто так.
Вообщем не надо из базы выдавать брать ID.
а как потом какой-нить дата инженер из кафки или из спарка данные будет заливать ? он должен будет свой мутный алгоритм генерации выдумывать или обязан будет пройти квест с поиском того кто такое выдумал?
Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен
Но если ваши ID расползутся по куче других систем, то с ними и прийдется жить. Хотя можно все и переписать
Andrey Strelnikov wrote: 29 Dec 2021 20:00
Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен
не понял вопроса. а на чем по вашему пишутся взрослые ETL ?
Andrey Strelnikov wrote: 29 Dec 2021 20:00
Те прямо в продакшн базу будет лить? Без ETL минимального? Всю команду перед этим расстреляют и сожгут всю документацию на систему?
Хотя это только мое мнение и с Вашим я заранее согласен
не понял вопроса. а на чем по вашему пишутся взрослые ETL ?
Понял. Мы про разные масштабы говорим. Я по простому и по старинке. Как сейчас в толстых корпоративах незнаю. Видимо везьде автоинкремент?
Где как, очевидно. У нас в одних таблицах sequence, в других max(id) + 1 (обычно secondary id). Разве что oracle вместо sql server, но тут однохренственно.
Вот есть несколько полей определяющих bank account:
Bank Name
Account Number
Account Type
Account Code
и т.д.
Как например без AccountID передавать это все в другие системы? Что по-вашему будет уникально определять bank account? Как эта другая система определит что пришел новый или обновился существующий? Только не говорите мне что комбинация всех этих (или нескольких) полей будет ключём. Меняется _все_ ... со временем.
KVA wrote: 29 Dec 2021 23:06
Ну а если серьезно по масштабному мыслить.
Вот есть несколько полей определяющих bank account:
Bank Name
Account Number
Account Type
Account Code
и т.д.
Как например без AccountID передавать это все в другие системы? Что по-вашему будет уникально определять bank account? Как эта другая система определит что пришел новый или обновился существующий? Только не говорите мне что комбинация всех этих (или нескольких) полей будет ключём. Меняется _все_ ... со временем.
AccountID будет autoincrement или сложносочиненным long(big)integer в этом случае?
KVA wrote: 30 Dec 2021 13:25
А чем разница когда AccountID уже попал в базу? Ну допустим мы может рассмотреть оба случая.
Оба случая я не встречал ни разу. А вот случай когда одна известная и толстая контора выдает составной ID(autoincrement + date), при этом сущность имеет еще и исторический autoincrement, знаю. Эти *** могут после ухода с рынка модели присвоить выданный ранее autoincrement новой модели - даже другой марки Этот случай вообще ломает миропорядок в системах клиентов. Видите ли нет у них лишних integer ID .
KVA wrote: 30 Dec 2021 15:13
А вы что берете external ID и используете его как primary key в вашей системе?
У нас все ОК. А вот ИХ external ID это имя сущности в предметной области. Так уже исторически сложилось. И расползлось по просторам. И на разборках приходится вытаскивать кучу старых бекапов входящих данных для поиска когда и что поменялось на входе. Хотя конечно толстой конторе эти разборки как укусы комара в броню.
KVA wrote: 30 Dec 2021 23:15 Ну ОК и как "имя сущности в предметной области" относится к "плохости" autoincrement ID?
Бизнес народ смотрит иногда и в системе вендора. По autoincrement ID. А клиентам часто недогружают к тому моменту ту же версию данных. Начинаются мелкие разборки - мелкие так как уже не в первый раз.
Хуже когда железка уже продана на месте. А данных этой физической уже версии нету. Приходится что-то "дарить" клиенту чтобы замять скандал.
Этот случай вообще ломает миропорядок в системах клиентов. Видите ли нет у них лишних integer ID .
Ну ОК и как "имя сущности в предметной области" относится к "плохости" autoincrement ID?