Ситуация, когда отдельные атрибуты должны ссылаться на другие сущности системы возникают достаточно редко, однако если бы возникло, то есть два решения. Для разовых случаев храним ссылку в json в качестве очередного атрибута, а целостность поддерживаем функциональными проверками, они кратко описаны в статье. Для более системного случая есть повод задуматься над выделением данного атрибута в отдельную сущность и разработки под него своего набора нативных аблиц со своим собственным атрибутным составом в json.
речь не про поиск клиентА, а про произвольную выборку клиентов по неселективному набору атрибутов. Попробуйте за 2 секунды найти всех Ивановых в Москве, у которых отчество заканчивается на ..вич :)
Отвечу, как один из основных разработчиков и идеологов системы, описанной выше. Неправильно говорить, что какие-то данные не нуждаются в нормализации, не понимая какие задачи перед нами стояли о каких данных идет речь.
Целостность и типизацию мы обеспечили через описанную выше инфраструктуру, в которую вложили несколько лет разработки. Эта инфраструктура гораздо более гибкая и масштабируемая, чем нативные возможности СУБД. Да, через нативные таблицы, многие вещи было бы проще реализовать, но проще - не значит лучше. И одна из основных идей статьи, как раз продемонстрировать, что грамотная реализация подобного хранения требует существенных вложений.
На счет скорости вопрос дискуссионный, нужны пруфы. Однако текущие потребности наша реализация вполне удовлетворяет, а ускорение ради ускорения не имеет смысла.
Если грамотно декомпозировать хранение данных в json, проблема с toast не возникнет примерно никогда. Я недавно смотрел ситуацию на нашей БД, там на десятки миллионов строк всего около 30 штук, у которых данные вылезли в toast, и их можно считать выбросами.
Ситуация, когда отдельные атрибуты должны ссылаться на другие сущности системы возникают достаточно редко, однако если бы возникло, то есть два решения. Для разовых случаев храним ссылку в json в качестве очередного атрибута, а целостность поддерживаем функциональными проверками, они кратко описаны в статье. Для более системного случая есть повод задуматься над выделением данного атрибута в отдельную сущность и разработки под него своего набора нативных аблиц со своим собственным атрибутным составом в json.
речь не про поиск клиентА, а про произвольную выборку клиентов по неселективному набору атрибутов. Попробуйте за 2 секунды найти всех Ивановых в Москве, у которых отчество заканчивается на ..вич :)
Отвечу, как один из основных разработчиков и идеологов системы, описанной выше. Неправильно говорить, что какие-то данные не нуждаются в нормализации, не понимая какие задачи перед нами стояли о каких данных идет речь.
Целостность и типизацию мы обеспечили через описанную выше инфраструктуру, в которую вложили несколько лет разработки. Эта инфраструктура гораздо более гибкая и масштабируемая, чем нативные возможности СУБД. Да, через нативные таблицы, многие вещи было бы проще реализовать, но проще - не значит лучше. И одна из основных идей статьи, как раз продемонстрировать, что грамотная реализация подобного хранения требует существенных вложений.
На счет скорости вопрос дискуссионный, нужны пруфы. Однако текущие потребности наша реализация вполне удовлетворяет, а ускорение ради ускорения не имеет смысла.
Если грамотно декомпозировать хранение данных в json, проблема с toast не возникнет примерно никогда. Я недавно смотрел ситуацию на нашей БД, там на десятки миллионов строк всего около 30 штук, у которых данные вылезли в toast, и их можно считать выбросами.