Хочу поддержать автора - очень интересно читать статью и разбираться. (Вообще ничего не понимаю в этом)
Слишком много критиков в комментариях. Ради интереса почитал разные астрономические статьи и форумы и у меня сложилось впечатление, что 99% там - это критики, которые сами ничего не предлагают и не исследуют - но тапками авторов закидывают знатно.
В 14 версии в последний раз тестировал JSONB - но вроде бы и в новых версиях ничего не поменялось. Архитектурно в pg работа с jsonb всегда будет медленнее, чем с нативными таблицами.
Основные данные по ИП/ЮЛ/ФЛ в большинстве случаев не нуждаются в нормализации и могут хранится либо в одной таблице (как по мне самый плохой вариант), так и в нескольких, например: organization, person, person_relation (для связи ФЛ c ЮЛ или с другими сущностями при необходимости). Возможно понадобится несколько сателитных сущностей для хранения данных "один ко многим" - но можно и без них обойтись.
Если Вас пугает большое кол-во джойнов - то тут можно воспользоваться view - которые замечательно профилируются и кэшируются в памяти и использовать их, как инфослой.
СУБД:
При использовании атрибутов (вместо JSON) - мы можем в БД использовать PK/FK c constraints - для обеспечения целостности данных.
Типизация данных позволяет экономить ресурсы при хранении и запросах + дополнительная валидация данных на уровне БД.
Масштабируемость - с нативными таблицами проще организовывать партицирование или шардирование.
Сортировка и группировка по нативным таблицам явно выигрывает по скорости у варианты с JSON (даже при наличии GIN).
С большей вероятностью часть JSON уйдут (при их разрастании) в TOAST - что создаст дополнительные расходы на их чтение и изменение.
Ужас. Никогда не делайте так, пожалуйста. JSON в РСУБД - это плохо. EAV, как принцип хранения всех основных данных в РСУБД - тоже плохо. В JSON хранят данные, которые нативно сохраняются с источника так: кликстримы, показатели с оборудования, конфиги и тд, с последующим преобразованием его в нормальный вид для аналитики, например. EAV используют в основном для хранения: сложных справочников многоуровневых, быстро меняющихся структур или плохо структурированных разряженных данных. Хранение данных по ФЛ/ИП/ЮЛ хорошо решается стандартными способами.
Это очень мало. Например, 1000 прогеров переписывается код, в среднем на 1пше в месяц уходит 500к, 12 месяцев (без учёта премий): 6млн на 1пше в год, тоесть 6млрд на 1000 сотрудников в год. Остальное на железо, поддержку и тд
Аналогичные проблемы, уже несколько недель. За год использования, колонка месяц работает хорошо, а потом несколько недель плохо.
Предполагаю, что за счёт железа (так как это облачное решение) и дополнительных оптимизаций и моддинга PG под него.
Хочу поддержать автора - очень интересно читать статью и разбираться. (Вообще ничего не понимаю в этом)
Слишком много критиков в комментариях. Ради интереса почитал разные астрономические статьи и форумы и у меня сложилось впечатление, что 99% там - это критики, которые сами ничего не предлагают и не исследуют - но тапками авторов закидывают знатно.
Так это бизнес же. AI "сам" же будет выбирать самый лучший товар.
В 14 версии в последний раз тестировал JSONB - но вроде бы и в новых версиях ничего не поменялось. Архитектурно в pg работа с jsonb всегда будет медленнее, чем с нативными таблицами.
Я и не планировал дискуссию, но давайте попробуем
Модель данных:
Основные данные по ИП/ЮЛ/ФЛ в большинстве случаев не нуждаются в нормализации и могут хранится либо в одной таблице (как по мне самый плохой вариант), так и в нескольких, например: organization, person, person_relation (для связи ФЛ c ЮЛ или с другими сущностями при необходимости). Возможно понадобится несколько сателитных сущностей для хранения данных "один ко многим" - но можно и без них обойтись.
Если Вас пугает большое кол-во джойнов - то тут можно воспользоваться view - которые замечательно профилируются и кэшируются в памяти и использовать их, как инфослой.
СУБД:
При использовании атрибутов (вместо JSON) - мы можем в БД использовать PK/FK c constraints - для обеспечения целостности данных.
Типизация данных позволяет экономить ресурсы при хранении и запросах + дополнительная валидация данных на уровне БД.
Масштабируемость - с нативными таблицами проще организовывать партицирование или шардирование.
Сортировка и группировка по нативным таблицам явно выигрывает по скорости у варианты с JSON (даже при наличии GIN).
С большей вероятностью часть JSON уйдут (при их разрастании) в TOAST - что создаст дополнительные расходы на их чтение и изменение.
Ужас. Никогда не делайте так, пожалуйста. JSON в РСУБД - это плохо. EAV, как принцип хранения всех основных данных в РСУБД - тоже плохо. В JSON хранят данные, которые нативно сохраняются с источника так: кликстримы, показатели с оборудования, конфиги и тд, с последующим преобразованием его в нормальный вид для аналитики, например. EAV используют в основном для хранения: сложных справочников многоуровневых, быстро меняющихся структур или плохо структурированных разряженных данных. Хранение данных по ФЛ/ИП/ЮЛ хорошо решается стандартными способами.
Вроде бы наоборот частично перешли на него. А "взрослые" архитекторы dwh, что нынче выбирают?
https://github.com/sytone/obsidian-remote
А кто то веб версию obsidian использует? Есть ли проблемы с ней?
Какая то часть свои сотрудники, часть аутсорс, интеграторы и тд + девопс, админы, po, руководство и тд
Это очень мало. Например, 1000 прогеров переписывается код, в среднем на 1пше в месяц уходит 500к, 12 месяцев (без учёта премий): 6млн на 1пше в год, тоесть 6млрд на 1000 сотрудников в год. Остальное на железо, поддержку и тд
Странно, что нет Князь 1/2/3
Метасистемный подход.
Я один ожидал, что он заполнит файл данными в конце)))?