Таким образом получим:
1. Затраты на диск (меньше всего волнует, но все же)
2. Более медленное обновление данных. Просто зарегистрировать объект к обмену со сторонней системой намного быстрее, чем обновить все подстроки в регистре поиска + обновить статистику
3. Бессмысленность регистра при популярных комбинациях
А в реальности придется делать подстроку не 6 символов (как в видео), а 3, что только усугубит ситуацию. Т.е. Elasticsearch выигрывает по всем пунктам еще и бонусом вы получаете поиск с учетом ошибок и морфологии. Ведь смысл же реализовать быстрый поиск, а не любыми путями сделать это на 1с пусть и с худшими показателями
По какому принципу вы собираетесь хранить весь текст по товарам и клиентам?
Просто первые три символа для каждого наименования товара, папки, вида номенклатуры, фио клиента, телефона и карты лояльности? Т.е. если у меня наименование «Вертикальный пылесос Samsung», то оператор уже не сможет найти «Пылесос Samsung»?
Или все-таки отдельными словами? Тут непонятный толк от такой фильтрации для, например, карт лояльности и номеров телефонов, т.к. они начинаются одинаково. Хотя здесь вы, наверное, ищете только по полному совпадению и отказываетесь от живого поиска, когда оператор видит фильтрацию в реальном времени. Но кроме этого же есть фамилии/имена, в которых первые 3 буквы повторяются очень часто (вам придется искать и по фамилии, и по имени, т.к. никто не гарантирует, что ФИО внесли в правильной последовательности). По какому принципу вы разбиваете по словам? Например, наименование товара «Браслет КТ 7405708/01-А552-01 01Б760365Ж.» (это реальный товар) как будет разбито? Сколько по вашим оценкам будет занимать первоначальное заполнение такого регистра (регистров?) и насколько хорошо будет происходить обновление данных? Какой объем будет занимать?
И не зависимо от способа заполнения еще вопрос: я так понимаю, что никакого поиска с учетом морфологии и синтаксических ошибок у вас быть не может как у авторов?
1. Затраты на диск (меньше всего волнует, но все же)
2. Более медленное обновление данных. Просто зарегистрировать объект к обмену со сторонней системой намного быстрее, чем обновить все подстроки в регистре поиска + обновить статистику
3. Бессмысленность регистра при популярных комбинациях
А в реальности придется делать подстроку не 6 символов (как в видео), а 3, что только усугубит ситуацию. Т.е. Elasticsearch выигрывает по всем пунктам еще и бонусом вы получаете поиск с учетом ошибок и морфологии. Ведь смысл же реализовать быстрый поиск, а не любыми путями сделать это на 1с пусть и с худшими показателями
Просто первые три символа для каждого наименования товара, папки, вида номенклатуры, фио клиента, телефона и карты лояльности? Т.е. если у меня наименование «Вертикальный пылесос Samsung», то оператор уже не сможет найти «Пылесос Samsung»?
Или все-таки отдельными словами? Тут непонятный толк от такой фильтрации для, например, карт лояльности и номеров телефонов, т.к. они начинаются одинаково. Хотя здесь вы, наверное, ищете только по полному совпадению и отказываетесь от живого поиска, когда оператор видит фильтрацию в реальном времени. Но кроме этого же есть фамилии/имена, в которых первые 3 буквы повторяются очень часто (вам придется искать и по фамилии, и по имени, т.к. никто не гарантирует, что ФИО внесли в правильной последовательности). По какому принципу вы разбиваете по словам? Например, наименование товара «Браслет КТ 7405708/01-А552-01 01Б760365Ж.» (это реальный товар) как будет разбито? Сколько по вашим оценкам будет занимать первоначальное заполнение такого регистра (регистров?) и насколько хорошо будет происходить обновление данных? Какой объем будет занимать?
И не зависимо от способа заполнения еще вопрос: я так понимаю, что никакого поиска с учетом морфологии и синтаксических ошибок у вас быть не может как у авторов?