Вы о какой СУБД? В mssql типы text и image хранятся в отдельных страницах всегда. Не поднимаются если не указаны в select. типы varchar и varbinary сохраняются в отдельных страницах при размере более 2000 байт.
В postgres то же самое происходит типами text и bytea по умолчанию, можно настроить чтобы они всегда сохранялись в TOAST (отдельных страницах)
Я уверен что и в других БД есть подобные механизмы.
С точки зрения клиента БД надо только в select не указывать поле, чтобы картинки даже с диска не считывались.
Конечно имеет. Язык и инфраструктура вокруг него создает культуру. Абстрактные факбрики билдеров (не штука) присутствуют ТОЛЬКО в жава программах, в других языках не замечено, хотя все средства имеются.
В CAP partition, consistency и availability это атомарные величины. В реальности - непрерывные. И вопрос звучит так: "сколько процентов доступности или согласованности вы готовы потерять при заданном проценте partition".
Пока вы работаете в одном датаценре, то можете считать что никаких partition у вас нет. Я знаю, что в облаке они могут случиться даже в рамках одного "региона", но это тоже крайне редкое явление.
CAP теорема не рассматривает поведение клиента. Если клиент умеет повторять запросы, то можно нивелировать "недоступность" по CAP и не только по CAP. Более того, повторяя запросы между серверами можно нивелировать partition.
Несмотря на весь маркетинг подавляющему большинству конечных потребителей нужна согласованность данных. Системы не обеспечивающие согласованность можно даже не рассматривать для прикладных задач.
CA-системы это давно известные и прекрасно работающие системы на основе кворума. Как и подавляющее большинство современных NoSQL баз.
AP-системы это кэш в том или ином виде над некоторым консистентным хранилищем или без него.
Комбинируя AP и CA системы можно выполнить нужные вам требования.
Может и увеличиться больше чем ккал набрали, но временно. Жир и гликоген могут удерживать воду, повышение уровня алкоголя или соли в крови тоже удерживает дополнительную воду в организме.
Различные отеки от воспалительных процессов в организме тоже удерживают дополнительную воду.
Вы о какой СУБД? В mssql типы text и image хранятся в отдельных страницах всегда. Не поднимаются если не указаны в select. типы varchar и varbinary сохраняются в отдельных страницах при размере более 2000 байт.
В postgres то же самое происходит типами text и bytea по умолчанию, можно настроить чтобы они всегда сохранялись в TOAST (отдельных страницах)
Я уверен что и в других БД есть подобные механизмы.
С точки зрения клиента БД надо только в select не указывать поле, чтобы картинки даже с диска не считывались.
С#, Python, TypeScript. Хотя в шарпе лет десять назад еще можно было встретить такую дичьЪ, но сейчас совсем нет.
Понятно что они все учли ошибки джавы, но почему в джава не учли?
Абстрактные Фабрики Билдеров это код примерно 2016 года написания, возможно до сих пор работает.
Если вы не делаете проекции, то вас на пушечный выстрел нельзя подпускать к базе. Какие вы там правила придумали сами себе - не важно.
А если они ошиблись? Массовые заблуждения не такая уж редкость как кажется.
И в чем проблема?
Что?
Виртуальный вызов дороже if
А с чего вы взяли что это разные сущности? Разделив данные пользователя и логин вы что выиграете?
Что значит "блокировать"? Вы обновляете поля a,b,c в одном методе, и поля x,y,z в другом.
Конечно имеет. Язык и инфраструктура вокруг него создает культуру. Абстрактные факбрики билдеров (не штука) присутствуют ТОЛЬКО в жава программах, в других языках не замечено, хотя все средства имеются.
Возможно есть разница между 1-to-1 и 1-to-0..1
Первое бесполезно чуть менее чем полностью, второе имеет право на жизнь для security, но мало выигрывает просто у одной таблицы.
В разных базах разные ограничения на типы и размеры, но в целом да
Текстовые поля можно хранить в отдельных страницах и не поднимать при каждом запросе.
Некоторые разработчики не умеют проектировать схему, а уживается все нормально если руки прямые
Вы в курсе что это все база данных умеет делать под капотом? Вам достаточно правильную проекцию написать.
Спустя 25 лет снова изобрели transaction script
Можно как-то привести два примера кода (не говнокода) и показать, что в одном есть clean architecture, а в другом нет?
Я чем больше читаю, тем больше понятно, что критерий нефальсифицируемости clean architecture не пройдет.
ИМХО если в статье про архитектуру нет кода, то статья скорее всего не имеет пользы.
Сколько можно это обсуждать:
В CAP partition, consistency и availability это атомарные величины. В реальности - непрерывные. И вопрос звучит так: "сколько процентов доступности или согласованности вы готовы потерять при заданном проценте partition".
Пока вы работаете в одном датаценре, то можете считать что никаких partition у вас нет. Я знаю, что в облаке они могут случиться даже в рамках одного "региона", но это тоже крайне редкое явление.
CAP теорема не рассматривает поведение клиента. Если клиент умеет повторять запросы, то можно нивелировать "недоступность" по CAP и не только по CAP. Более того, повторяя запросы между серверами можно нивелировать partition.
Несмотря на весь маркетинг подавляющему большинству конечных потребителей нужна согласованность данных. Системы не обеспечивающие согласованность можно даже не рассматривать для прикладных задач.
CA-системы это давно известные и прекрасно работающие системы на основе кворума. Как и подавляющее большинство современных NoSQL баз.
AP-системы это кэш в том или ином виде над некоторым консистентным хранилищем или без него.
Комбинируя AP и CA системы можно выполнить нужные вам требования.
Опять юлите, путая мгновенную и среднюю скорость.
Открою тайну: БЖУ и калорийность готовых блюд высчитывается как сумма исходных продуктов.
Да и в целом при термообработке БЖУ не меняются, так что достаточно точная величина.
Может и увеличиться больше чем ккал набрали, но временно. Жир и гликоген могут удерживать воду, повышение уровня алкоголя или соли в крови тоже удерживает дополнительную воду в организме.
Различные отеки от воспалительных процессов в организме тоже удерживают дополнительную воду.