Сообщение Зачем реляционные БД...в небольших проектах? от 05.02.2021 14:25
Изменено 05.02.2021 14:27 IncremenTop
Зачем реляционные БД...в небольших проектах?
Вакансия:
"-Разработка высоконагруженного бэкенда для медицинского приложения;
базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"
Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
[img]https://lh3.googleusercontent.com/proxy/uflg08WgbKxyJ8-gv70XCWRu30Cmk9MytS0EZnAGz_wig2r_2ddg3IiRCNDqr04IfZmWCKlpDz4GcAuMAk0HBx7gaIqMDVqjl68BokIkfvrdGGzlUBAUuDSEPQ[img]
И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
"-Разработка высоконагруженного бэкенда для медицинского приложения;
базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"
Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
[img]https://lh3.googleusercontent.com/proxy/uflg08WgbKxyJ8-gv70XCWRu30Cmk9MytS0EZnAGz_wig2r_2ddg3IiRCNDqr04IfZmWCKlpDz4GcAuMAk0HBx7gaIqMDVqjl68BokIkfvrdGGzlUBAUuDSEPQ[img]
И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
Зачем реляционные БД...в небольших проектах?
Вакансия:
"-Разработка высоконагруженного бэкенда для медицинского приложения;
базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"
Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
"-Разработка высоконагруженного бэкенда для медицинского приложения;
базовые принципы современной разработки ПО: IoC/DI, слабая связанность, разделение по слоям и компонентам, логирование, пригодность кода для юнит-тестирования;
отличное знание любой промышленной реляционной базы данных: нормализация/денормализация таблиц, представления, индексы, хранимые процедуры, оптимизация запросов;
опыт разработки с помощью фреймворков для MS .Net ASP.Net MVC / WebAPI;
организация доступа к БД SQL из кода MS.Net: Entity Framework, преимущества и ограничения использования ORM;
опыт участия в разработке высоконагруженных и масштабируемых сервисов;
распараллеливание вычислений, доступ к данным, кэширование, опыт использования RabbitMQ для транспорта сообщений;"
Я понимаю, когда монолит лазит к одной БД, но когда куча микросервисов лазит к одной бд, в которой еще и логика, то получается вот такое:
И ведь это учудил архитектор в далеко не рядовой компании — Реннесанс.
Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.