|
|
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Интересно, как правильнее реализовать работу с "интересами", как это сделано, например, на LiveJournal.com Там у каждого пользователя есть произвольных набор "интересов", то есть ключевых слов, по которым этого пользователя можно найти. Эти ключевые слова через запятую пользователь сам задает у себя в профиле. Как правильнее хранить такую информацию и искать по ней пользователей. Я вижу два варианта: 1. Хранить в большой таблице пары значений int user_id, char interest при этом строка interest у разных пользователей может совпадать, то есть повторяется в таблице многократно. При поиске строка interest выступает в роли ключа. 2. Хранить в большой таблице пары int user_id, int interest_id, при этом все строки с "интересами" будут храниться в отдельной таблице int interest_id, char interest_name. Вопрос в том, что экономнее по времени и по памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2006, 22:44 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
По варианту 2: тут особо не наэкономишь, а мороки лишней будет много. Полагаю, речь не идет о таких уж объемах, чтобы надо было экономить. Другой вопрос, если этот поиск по интересом очень важен. Тут можно поморочится, вроде приведения ключевых слов к единой морфологии или выбора их из списка, устранения опечаток и т.д. Тут 2 вариант может и получше будет. Но судя по задаче, возможность поиска по интересам --- побочная фича, так что это все лишнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 06:34 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Хм. И какого рода морока будет во втором варианте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 09:48 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Поиск по интересам будет, скорее всего, использоваться не так часто, однако вот количество интересов будет весьма значительно. Например, если пользователей станет много (десятки, а то и сотни тысяч), на каждого будет приходиться примерно по 15 ключевых слов, то есть вполне возможно, что число записей перевалит за миллион. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:10 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Второй вариант мне больше нравится тем, что a) поиск по int идет быстрее, чем по строкам b) экономится память, за счет удаления многократных повторений строк. С этим вариантом возиться действительно нужно гораздо больше, чем с первым (добавление интересов, из редактирование и тд). Вот и хотелось бы знать, стоит ли игра свеч. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:14 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Я не понимаю, что со вторым вариантом возиться-то? INSERT IGNORE и JOIN при заполнении, JOIN при извлечении информации. Причём JOIN простейший, по первичному ключу! Для денормализации базы должны быть какие-то основания, тут их просто нету, так зачем же сразу портачить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:21 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
DocAlЯ не понимаю, что со вторым вариантом возиться-то? INSERT IGNORE и JOIN при заполнении, JOIN при извлечении информации. Причём JOIN простейший, по первичному ключу! Для денормализации базы должны быть какие-то основания, тут их просто нету, так зачем же сразу портачить?Да можно и 2 вариант, конечно, спору нет. На один джойн больше, плюс посложнее парсинг ввода. Кстати, что такое INSERT IGNORE? И еще, где ж тут денормализация была? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:55 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
flyingheroВторой вариант мне больше нравится тем, что a) поиск по int идет быстрее, чем по строкам Конечно. И условия удобно задавать: Найди ка мне людей с 10, 48 и 23 -м интересом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 11:57 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Слабости РБД в целом и "ключей" в частности проявляются в любой задаче. В классической ОБД: Человек <-- Имеет/Присутствует у --> Интерес Хотя можно использовать и характеристику "Интерес" с типом "набор строк" в объекте Человек. Странно, что такой специалист, как mir, не видит, в этом случае, денормализации. Видимо это связано со слабой "технологией" нормализации в РБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 12:46 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
mir DocAlЯ не понимаю, что со вторым вариантом возиться-то? INSERT IGNORE и JOIN при заполнении, JOIN при извлечении информации. Причём JOIN простейший, по первичному ключу! Для денормализации базы должны быть какие-то основания, тут их просто нету, так зачем же сразу портачить?Да можно и 2 вариант, конечно, спору нет. На один джойн больше, плюс посложнее парсинг ввода. Кстати, что такое INSERT IGNORE? И еще, где ж тут денормализация была? Так в чём состоит более сложный парсинг ввода? Подозреваю, что эта "более сложность" и заменяет у вас INSERT IGNORE ,) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 12:49 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
К тому же, "интерес" может быть любительский или подкрепленный образованием и т.д. Так что денормализация не выглядит здесь обоснованной, совершенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 12:52 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
iscrafm flyingheroВторой вариант мне больше нравится тем, что a) поиск по int идет быстрее, чем по строкам Конечно. И условия удобно задавать: Найди ка мне людей с 10, 48 и 23 -м интересом Если это сарказм, то он тут неуместен. Джойн по первичному ключу -- штука быстрая, а выборка по строчным значениям из тысячи уникальных записей будет куда быстрее выборки по миллиону неуникальных. Я вообще, не особо понимаю, о чём идёт спор. Второй предлагаемый вариант является классической нормализованной структурой, в которой под сущность "интерес" выделена отдельная таблица. Первый же -- некая полумера между "зафутболить все интересы в строку через запятую" и нормальной реализацией. Если вы видите преимущества такого решения -- так покажите их, только, пожалуйста, с примерами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 12:56 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
iscrafm flyingheroВторой вариант мне больше нравится тем, что a) поиск по int идет быстрее, чем по строкам Конечно. И условия удобно задавать: Найди ка мне людей с 10, 48 и 23 -м интересом поиск будет происходить всегда по одному интересу. т.е предварительно можно выбрать из таблицы интересов id интереса, а потом искать по нему. Я полагаю, это быстрее всяких джойнов будет. вы меня почти убедили в целесообразности второго варианта :) правда, честно говоря, про INSERT IGNORE не слышал никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2006, 15:40 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
По-моему возни со вторым вариантом все равно не избежать. Например пользователь задал себе несколько ключевых слов. Из них надо в таблицу с интересами вставить только новые, вместе с тем получить id этих новых + получить id остальных неновых интересов. Затем нужно из таблицы пользователь-интерес удалить все записи конкретного пользователя и записать на их место только что полученные id интересов. INSERT IGNORE здесь вообще никак не помогает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2006, 01:03 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Нда? Ну вот вам пример. Синтаксис MySQL, потому что-то может различаться для других диалектов, конечно. Описание основных таблиц: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2006, 08:15 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Спасибо, не додумался :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2006, 12:31 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
DocAl mir DocAlЯ не понимаю, что со вторым вариантом возиться-то? INSERT IGNORE и JOIN при заполнении, JOIN при извлечении информации. Причём JOIN простейший, по первичному ключу! Для денормализации базы должны быть какие-то основания, тут их просто нету, так зачем же сразу портачить?Да можно и 2 вариант, конечно, спору нет. На один джойн больше, плюс посложнее парсинг ввода. Кстати, что такое INSERT IGNORE? И еще, где ж тут денормализация была? Так в чём состоит более сложный парсинг ввода? Подозреваю, что эта "более сложность" и заменяет у вас INSERT IGNORE ,)И все же, что такое INSERT IGNORE? По-моему, в стандарте такого нет. Если это нестандартная фича MySQL, то почему вы ее столь активно предлагаете, ведь в исходной постановке ни слова не говорилось об используемой СУБД. Если автор вопроса заведомо использует MySQL, то спора нет. Если же не заведомо, то попробуйте реализовать ваш подход без INSERT IGNORE. Вот тут-то, полагаю, и вылезут дополнительные сложности, о которых я и говорил. Кстати, на вопрос про денормализацию вы так и не ответили. Какая НФ нарушена и почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 08:59 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
При указании ключевого слова IGNORE, оператор INSERT обрабатывает ошибки, возникшие при внесении данных как предупреждения. Эффективно, в таком применении, как приводилось в примере, это означает, что все вносимые записи, не удовлетворяющие ограничениям уникальности (или любым другим CONSTRAINT, в общем случае) игнорируются. Т.к. у каждой СУБД свой диалект, в чём-то расширяющий стандарт, а в чём-то ему и не соответствующий, я не вижу причины, почему бы мне не приводить пример на основе одного из наиболее часто используемых в вебе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 13:17 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
DocAlПри указании ключевого слова IGNORE, оператор INSERT обрабатывает ошибки, возникшие при внесении данных как предупреждения. Эффективно, в таком применении, как приводилось в примере, это означает, что все вносимые записи, не удовлетворяющие ограничениям уникальности (или любым другим CONSTRAINT, в общем случае) игнорируются. Т.к. у каждой СУБД свой диалект, в чём-то расширяющий стандарт, а в чём-то ему и не соответствующий, я не вижу причины, почему бы мне не приводить пример на основе одного из наиболее часто используемых в вебе.Про смысл INSERT IGNORE я так примерно и думал. В принципе, полезная штука. Правда вы должны признать, что все таки очень специфичная, поэтому налегать на нее с самого начала обсуждения, как делали вы, было, хм... не вполне корректно, так как автор темы про СУБД ничего не оговорил. Ладно, пора заканчивать. P.S. Про денормализацию в 1 варианте, будем считать, вы сгоряча брякнули, не подумав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 15:24 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
Хм, да собственно, 2НФ нарушается, вроде бы очевидно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 15:53 |
|
||
|
Хранение и поиск текстовых строк
|
|||
|---|---|---|---|
|
#18+
DocAlХм, да собственно, 2НФ нарушается, вроде бы очевидно? Да, а вот это я действительно погорячился.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2006, 16:04 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33823619&tid=1545157]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
386ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 702ms |

| 0 / 0 |
