SA
Нынче с трендами типа serverless и прочие распределенные штуки как-то о других вещах приходится париться в контексте "eventual consistency" (тот же event storming)
Тренды-трендами, но data warehouse со сложной структурой никто не отменял
Size: a a a
2020 September 29
SP
Как там говорил Грег Янг - "так мы возьмём оракл, гибернейт, спринг - что мы делаем? Вы делаете калькулятор..."
SP
Тренды-трендами, но data warehouse со сложной структурой никто не отменял
Ну дата вэрхаусы это все ж второстепенные штуки и там могут работать принципы федераций базы и прочее и в целом я не видел пока компаний которые это адекватно юзабт
SA
Ну дата вэрхаусы это все ж второстепенные штуки и там могут работать принципы федераций базы и прочее и в целом я не видел пока компаний которые это адекватно юзабт
А я работал в страховании, я видел.
SA
Но в целом удивительно - концепция "проектирование приложения начинается с проектирования его модели данных" ни у кого удивления не вызывает, а тот факт, что самая важная и стабильная модель данных - это схема БД как-то забывается.
SP
Но в целом удивительно - концепция "проектирование приложения начинается с проектирования его модели данных" ни у кого удивления не вызывает, а тот факт, что самая важная и стабильная модель данных - это схема БД как-то забывается.
Потому что когда мы говорим про схемы у людей все начинает в таблички упираться а моделирование данных концепт куда интереснее
m
Но в целом удивительно - концепция "проектирование приложения начинается с проектирования его модели данных" ни у кого удивления не вызывает, а тот факт, что самая важная и стабильная модель данных - это схема БД как-то забывается.
человек из мира оракла и процедур?)
SP
Тот же event storming это ничто иное как "моделирование данных" при этом ничего "похожего" на типичные er диаграммы там нет
SA
человек из мира оракла и процедур?)
Нет, хотя я и с таким поработать успел)
SA
Тот же event storming это ничто иное как "моделирование данных" при этом ничего "похожего" на типичные er диаграммы там нет
довольно странно называть моделированием процесс, на выходе которого нет модели)
k
довольно странно называть моделированием процесс, на выходе которого нет модели)
а схема бд - это модель?
SP
довольно странно называть моделированием процесс, на выходе которого нет модели)
Там есть модель, просто тебе может быть не привычна такая модель
SP
Но в целом это даже красиво называется - temporal modeling :)
АГ
database first. фигачишь миграцию, потом модель для работы с данными, потом уже бизнес логику. обычный подход, многие так привыкли, так проще
МФ
P.s. мне как-то не доводилось работать с продуктами где проектирование бд это что то "с чего стоит начинать"
Интересно, в процедурном программировании тоже хорошим тоном является code first?
АГ
если дата маппер, то database first не получится, т.к. автоподгон схемы бд под классы сущностей идет.
SP
Интересно, в процедурном программировании тоже хорошим тоном является code first?
Все эти модные штуки как бэ придумывались немного раньше бума популярности ооп. Где то в середине 70-х
SP
Про crc карточки для классов тоже в прошлом веке ещё писали
SP
Ну и в целом это не про code first. Это о том что сначала юзкейсы а потом сущности и какие данные юзкейсам нужны. А когда люди начинают "базы проектировать" часто это выглядит как "шо у кастомера адрес есть? Збс, добавим в табличке customers ещё поле!"
SP
Когда люди проектируют базу а потом код генерят в целом есть вопрос а нужен ли там код раз в целом оно все можно сгегерить