Highload и реляционная СУБД плохо совместимы, для highload другие БД обычно используются, минимальное требование - горизонтальная масштибируемость на запись, с этим у реляционных БД все плохо, на чтение ещё можно репликами разрулить, а вот если высокая нагрузка на запись, то приходиться танцевать с бубнами и менять структуру БД чтобы можно было сегментировать хранилище по разным дискам, пока не упрёшся в лимит по CPU, а уж по разным узлам разносить логически одно хранилище, это отдельная боль.
Конечно нет, коллация в MSSQL по умолчанию регистронезависимая в отличии от Postgres и далее начиная с пагинации, регистронезависимые ILIKE и до оконных функций - много отличий, даже в типах данных дат, я молчу про json функции.
Боль начинается из за отказа от унификации и острого желания найти уже готовую фичу в конкретной специфичной БД и пользоватся ею независимо от последствий в будущем - привязал проект к конкретной СУБД и точка, зато все быстро сделал - менеджеры таких любят.
Кстати, ни в коем случае не берите на работу тех, кто сможет объяснить менеджерам почему теперь мы не можем отказатся от этой технологии и использовать аналогичное open source решение :)
ORM позволяет стандартизировать интерфейс доступа к данным, пожертвовав гибкостью конкретной СУБД, в пользу унификации. Такой подход влияет на архитектуру кода.
Спасибо за статью. Оказывается если класс использовать для задач, для которых он не предназначен, то он не сработает! Не знал, что такое бывает. :)
Проблема конечно в стремлении понадобавлять разных методов во вполне себе хорошие классы, при этом не объяснив джунам, что лучше этими методами не пользоватся либо пользоватся понимая ограничения. Но, кто будет разбиратся и вдумыватся о возможных проблемах? Таких единицы.
Описанная вами проблема не решается ни одним классом, так как само решение нетревиальное и ненадёжное.
Решение - при отсутсвии ключа в кэше, первый вызов, записывается ключ и статус "не готово", затем запускается метод получения данных, после того как метод завершён, данные помещаются в кэш и статус меняется на "готово". Во время получения данных все вызовы из других потоков с этим ключём встают в ожидание - в идеале подписываются на событие и ожидают завершения получения данных.
Это основной, успешный сценарий. но есть и альтернативные - когда данные не удалось получить. Что делать в этом случае? :)
Вот тут и начинается самое интересное, и сценариев может быть множество. Эти сценарии сильно зависят от вашей задачи и пихать их в библиотеку .NET никто не будет - ибо дело неблагодарное :)
Как минимум наличие встроенных альтернативных сценариев подразумевает наличия настроек для них, например - количество попыток получить данные, время ожидания получения данных, и наконец просто флага включения сценария по умолчанию, который в данном случае мало кому пригодится - так как давка кэша проблема специфичная для сложных приложений, а её негативное проявление будет только при большой нагрузке.
Вывод - если этих настроек нет, значит в классе нет реализации альтернативных сценариев. Если нет альтернативных сценариев, то нет и никакого кода для решения проблемы.
Как видите, не нужно проводить исследования, чтобы по косвенным признакам определять границы сложности класса. Достаточно просто посмотреть на класс и сказать "он слишком прост для решения этой сложной проблемы".
Хорошая попытка убедить в собственной полезности, но нет, не убедительно.
Все врут, все иммитируют вовлеченность и заинтересованность, реальная и единственная мотивация у 99,9% сотрудников - получать зарплату.
"Напустить туману" распространённый паттерн сокрытия некомпетентности :)
Highload и реляционная СУБД плохо совместимы, для highload другие БД обычно используются, минимальное требование - горизонтальная масштибируемость на запись, с этим у реляционных БД все плохо, на чтение ещё можно репликами разрулить, а вот если высокая нагрузка на запись, то приходиться танцевать с бубнами и менять структуру БД чтобы можно было сегментировать хранилище по разным дискам, пока не упрёшся в лимит по CPU, а уж по разным узлам разносить логически одно хранилище, это отдельная боль.
Конечно нет, коллация в MSSQL по умолчанию регистронезависимая в отличии от Postgres и далее начиная с пагинации, регистронезависимые ILIKE и до оконных функций - много отличий, даже в типах данных дат, я молчу про json функции.
Боль начинается из за отказа от унификации и острого желания найти уже готовую фичу в конкретной специфичной БД и пользоватся ею независимо от последствий в будущем - привязал проект к конкретной СУБД и точка, зато все быстро сделал - менеджеры таких любят.
Кстати, ни в коем случае не берите на работу тех, кто сможет объяснить менеджерам почему теперь мы не можем отказатся от этой технологии и использовать аналогичное open source решение :)
ORM позволяет стандартизировать интерфейс доступа к данным, пожертвовав гибкостью конкретной СУБД, в пользу унификации. Такой подход влияет на архитектуру кода.
Статья о том как не быть а казатся. Это очень востребовано.
Спасибо за статью. Оказывается если класс использовать для задач, для которых он не предназначен, то он не сработает! Не знал, что такое бывает. :)
Проблема конечно в стремлении понадобавлять разных методов во вполне себе хорошие классы, при этом не объяснив джунам, что лучше этими методами не пользоватся либо пользоватся понимая ограничения. Но, кто будет разбиратся и вдумыватся о возможных проблемах? Таких единицы.
Описанная вами проблема не решается ни одним классом, так как само решение нетревиальное и ненадёжное.
Решение - при отсутсвии ключа в кэше, первый вызов, записывается ключ и статус "не готово", затем запускается метод получения данных, после того как метод завершён, данные помещаются в кэш и статус меняется на "готово". Во время получения данных все вызовы из других потоков с этим ключём встают в ожидание - в идеале подписываются на событие и ожидают завершения получения данных.
Это основной, успешный сценарий. но есть и альтернативные - когда данные не удалось получить. Что делать в этом случае? :)
Вот тут и начинается самое интересное, и сценариев может быть множество. Эти сценарии сильно зависят от вашей задачи и пихать их в библиотеку .NET никто не будет - ибо дело неблагодарное :)
Как минимум наличие встроенных альтернативных сценариев подразумевает наличия настроек для них, например - количество попыток получить данные, время ожидания получения данных, и наконец просто флага включения сценария по умолчанию, который в данном случае мало кому пригодится - так как давка кэша проблема специфичная для сложных приложений, а её негативное проявление будет только при большой нагрузке.
Вывод - если этих настроек нет, значит в классе нет реализации альтернативных сценариев. Если нет альтернативных сценариев, то нет и никакого кода для решения проблемы.
Как видите, не нужно проводить исследования, чтобы по косвенным признакам определять границы сложности класса. Достаточно просто посмотреть на класс и сказать "он слишком прост для решения этой сложной проблемы".
Вопрос то неверный, верный вопрос - а что так? Вы пробовали их "продукцию"? Я вот однажды "имел несчастье".
Сплошной маркетинг с таргетингом на эмоции, я об этом и говорил
Коала лицие :)
Acronis... Вы серьёзно?
молодцы конечно, но что там у них внутри происходит информации нет.
Ответ банален - так больше инвесторов, попробуйте объянсить что схема паука более эффективная - денег не получите, пауки такие противные...
Манипуляторы нужны, но причем тут антропоморфность?
Новость уровня - наши повора научились жарить картофель.
Вопрос, в Go до сих пор нет ORM? Хотя бы аналог Dapper для C#, ну или что то более серьёзное типа EF?
Видимо и тут научились распиливать :)
Обещал - сделал
https://habr.com/ru/articles/976940/