LINUX.ORG.RU

Работа с множествами

 


0

1

Не подскажите как наиболее эффективно работать со множествами? Что почитать?

Задача Есть неограниченное число множеств A,B,C..N есть объекты а, b, c ... n

каждый объект может оказаться в нескольких множествах т.е. объект «а» может быть в A,C или может не быть.

Как наиболее эффективно проверить находится ли он в множестве или нет (возможно какое-то побитовое сравнение)? Задача связана с web с тэгированием данных.

как сейчас реализовано: есть в таблице `users` поле tags В нём хранятся тэги вида #a#, #b#, #c# .. Есть зона видимости юзер login_a видит множество #a# и #b#. Чтобы выбрать всех пользователей которые находятся в множестве #a# или #b# поиск идет простым лайком - SELECT * FROM `users` WHERE `tags` LIKE '%#a#%' OR `tags` LIKE '%#b#%'

Соответственно при росте данных и множеств начинает все дико тупить. Естественно немного спасёт нормализация таблиц (создание дополнительных таблиц с группами) или использование full text поиска чем нибуть типа sphinx. Но возможно что-то более правильное придумать чтобы сохранялась таже математическая модель?

Уходить в тип SET с множествами для таблиц не хочется из-за его ограничения на количество множеств.

★★

Лучше сделать тблицу, в которой хранятся упорядоченне пары (пользовтель, группа), и позволить БД создть индексы для быстрой выборки.

Deleted
()
Ответ на: комментарий от drBatty

Я же говорю что с нормализацией все понятно. Интересуют более специфичные методы для той же математической модели, типа побитового сравнения, возможно что-то еще...

ppy ★★
() автор топика
Ответ на: комментарий от ppy

У нормализации при всех плюсах есть свои недостатки, что в итоге таблица с парами вырастет и JOIN который добавится к каждому запросу при росте данных также начнёт тормозить, и затем от нормализованных таблиц будет избавиться сложнее.

Но видимо так и будем делать если не придумается ничего лучше.

Если коротко, то нужен бесконечный тип SET с очень быстрой выборкой.

ppy ★★
() автор топика
Последнее исправление: ppy (всего исправлений: 1)
Ответ на: комментарий от ppy

Но и SET немного не то, т.к. создание множеств отдано пользователю, и ALTER TABLE делать на каждое создание не реально.

ppy ★★
() автор топика
Ответ на: комментарий от ppy

Интересуют более специфичные методы для той же математической модели, типа побитового сравнения, возможно что-то еще...

в LIKE ЕМНИП и так shift-and, оно и так сразу по 8 символов проверяет сразу(в ASCII для x64), куда быстрее-то?

Можешь ещё вот это попробовать: http://dev.mysql.com/doc/refman/5.1/en/fulltext-search.html

drBatty ★★
()
Ответ на: комментарий от ppy

Если коротко, то нужен бесконечный тип SET с очень быстрой выборкой.

таблица связей, какая-то нормальная форма. Всё остальное - только хуже.

drBatty ★★
()
Ответ на: комментарий от drBatty

вы уверены?

Не думаю что в каком-нибуть google+ для проверки видимости одного юзера другим нормализованные таблицы и JOIN по ним используются.

ppy ★★
() автор топика
Ответ на: комментарий от ppy

вы уверены?

нет конечно. ТЗ то я не видел.

Не думаю что в каком-нибуть google+ для проверки видимости одного юзера другим нормализованные таблицы и JOIN по ним используются.

вот что вы к нормализации прицепились? Связи могут быть и не нормализованные, дело не в этом, а в том, что используются обычно СВЯЗИ для таких соответствий. А всякие SET - оптимизация, для жёстко фиксированных множеств. Нормальные формы - обобщённый подход для случая сферического вакуума, абстрактное правило, не более того. И что за проверка «JOIN», если простого SELECTа достаточно для проверки связи?

И да, СУБД если может, то должна САМА использовать побитные операции, SSE4.2 и прочую НЁХ тогда, когда это нужно и можно. Не забивайте голову.

drBatty ★★
()
Ответ на: комментарий от drBatty

ок, спасибо!

Не забивайте голову.

Да, скорее всего вы правы. Нужно делать стандартную нормализацию.

ppy ★★
() автор топика
Ответ на: комментарий от ppy

Нужно делать стандартную нормализацию.

ага. вот прочтите это: http://ru.wikipedia.org/wiki/Оптимизация_(информатика)

для Ъ> Оптимизация должна проводиться с осторожностью. Тони Хоар впервые произнёс, а Дональд Кнут впоследствии часто повторял известное высказывание: «Преждевременная оптимизация — это корень всех бед». Очень важно иметь для начала озвученный алгоритм и работающий прототип.

вы как раз этим и занимаетесь, надо сначала создать алгоритм, а потом уже его оптимизировать. Если у вас нет какой-то структуры, то значит вы что-то делаете не так.

drBatty ★★
()

Не подскажите как наиболее эффективно работать со множествами?

очень общая задача. какова максимально возможная мощность множества? 1? 8? 32? 64? 128? 1024? 4096? 65356? заведомо больше наперёд заданной константы?

(тут N много больше n) в каком отношении частоты добавление в множество к исключение из множества к проверка на принадлежность? 1:1:1? n:1:1? N:n:1? 1:0:n? n:1:N? как либо ещё?

Что почитать?

Гуглить «досрочная оптимизация корень зол»

Гуглить «программирование есть умение размышлять о ситуации на нескольких уровнях абстракции одновременно»

Гуглить «покажите мне используемый код и я не пойму , покажите используемые структуры данных и я пойму »

Но возможно что-то более правильное придумать чтобы сохранялась та же математическая модель?

печаль

qulinxao ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.