Я не скажу за все БД, но в MSSQL, MySQL и PostgreSQL блобы размером 10мб будет храниться в отдельных страницах. А если правильные типы подобрать, то оверхед от блобов будет не больше одного указателя в основных страницах таблицы. И почему-то я уверен что в Oracle будет также.
В "общем случае" можно сделать по таблице на поле, но это займет сильно больше места и будет сильно дольше будет работать на любой проекции где больше одного поля.
Прикол в том, что нам зачастую надо ускорять сложные запросы, а не примитивные. Для примитивных вообще можно сделать покрывающие индексы.
Вы о какой СУБД? В mssql типы text и image хранятся в отдельных страницах всегда. Не поднимаются если не указаны в select. типы varchar и varbinary сохраняются в отдельных страницах при размере более 2000 байт.
В postgres то же самое происходит типами text и bytea по умолчанию, можно настроить чтобы они всегда сохранялись в TOAST (отдельных страницах)
Я уверен что и в других БД есть подобные механизмы.
С точки зрения клиента БД надо только в select не указывать поле, чтобы картинки даже с диска не считывались.
Конечно имеет. Язык и инфраструктура вокруг него создает культуру. Абстрактные факбрики билдеров (не штука) присутствуют ТОЛЬКО в жава программах, в других языках не замечено, хотя все средства имеются.
Легко: Укладываем все в одну таблицу.
Я не скажу за все БД, но в MSSQL, MySQL и PostgreSQL блобы размером 10мб будет храниться в отдельных страницах. А если правильные типы подобрать, то оверхед от блобов будет не больше одного указателя в основных страницах таблицы. И почему-то я уверен что в Oracle будет также.
В "общем случае" можно сделать по таблице на поле, но это займет сильно больше места и будет сильно дольше будет работать на любой проекции где больше одного поля.
Прикол в том, что нам зачастую надо ускорять сложные запросы, а не примитивные. Для примитивных вообще можно сделать покрывающие индексы.
У вас любой запрос лочит строки. Лок двух срок в двух таблицах съест чуть больше ресурсов, чем лок одной строки в одной таблице.
И как вы собрались не лочиться? Запрос у вас полюбому повесит rowlock как минимум на одну строку.
конечно же нет. https://sqlity.net/en/1051/blob-and-row-overflow-storage-internals-row-overflow-data/
А еще индекс может оказаться покрывающим
Вы о какой СУБД? В 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 не пройдет.