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

[karlos]

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

Вкратце о сути проблемы:
Имеется поле "user_from", где значением может быть либо одно слово, либо несколько с разделителями (предпочтителен не пробел, а какой либо знак препинания).
Задача: вывести список уникальных значений этого поля. Если бы в поле было одно слово, то задача решается простым запросом, например таким (+ с сортировкой и подсчетом):

SELECT user_from, COUNT( * ) AS count
FROM phpbb_users
GROUP BY user_from
ORDER BY `user_from` ASC

но - хотелось бы как-то распарсить несколько слов из одного поля, что бы они в результатах выдачи выдавались отдельно.
Плюс, еще в идеале, для каждого значения ссылочку на список пользователей.

Более наглядно: чел вводит в профиле в поле "откуда" список городов через запятую. А на отдельной странице видим список городов, где они находятся в разных строчках. На каждом сцыла, по которой видим список пользователей из этого города.

Кстати, возможно что-то подобное уже и реализовано где-то, но мне как-то не попадалось

Буду благодарен за любую подсказку! Спасибо.

 

[Wicked]

Вам прямая дорога к архитектуре, где эта информация будет храниться не в одном поле через запятую, а в соседней таблице в столбик - в каждой записи по одному городу. Тогда все, что нужно, делается на раз-два. И парсить введенную строку придется только один раз - при вставке. Это для начала

 

[karlos]

Автор оригинала: Wicked
Вам прямая дорога к архитектуре, где эта информация будет храниться не в одном поле через запятую, а в соседней таблице в столбик - в каждой записи по одному городу. Тогда все, что нужно, делается на раз-два. И парсить введенную строку придется только один раз - при вставке. Это для начала

я об этом уже думал. По сути я хочу "выдирать" значения из вручную добавленного поля в профиле. Но, помнится, это добавление было связано с некоторым гемором. И потом, реалии таковы, что сейчас это поле уже заполнено значениями через запятую. Можно, конечно, все-таки взяться собраться с силами и добавить еще штук 5-10 полей, а потом упросить пользователей отредактировать профиль (либо самому ручками за них, благо, пока не так много записей), но думалось, что существует более элегантное решение проблемы , земляк

 

[Фанат]

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

 

[karlos]

угу, я понял мнение большинства
Забыл упомянуть - это я пытаюсь кастомизировать phpbb форум под себя...

 

[Фанат]

Это не мнение.

 

[karlos]

т.е. вы хотите сказать, что именно архитектурное решение создаст меньшую нагрузку на систему?

 

[Фанат]

написанный на ассемблере демон создаст меньшую нагрузку на систему, чем пхп скрипт выполняемый веб-сервером.
срочно начинай переписывать.
ведь нагрузка на систему - единственный критерий, верно?..

 

[karlos]

вобщем-то скорость выполнения запроса (загрузки страницы), думаю, тоже не последнюю роль играет. Но если выдавать результат постранично - наверное, со скоростью проблем не будет. (Если это вообще как-то может повлиять на скорость)

 

[Фанат]

У тебя просто никакие представления о скорости.
Даже о скорости. при том, что это единственный критерий оценки архитектуры системы, который тебе доступен.

Если я отправлю тебя читать про нормализацию баз данных, ты, разумеется, по примеру всех остальных посетителей этого форума, оскорбишься.
поэтому просто поверь мне на слово - кроме хранения в отдельной таблице, других вариантов просто не бывает.

 

[karlos]

Нет, не оскорблюсь, но постоянный цейтнот вынуждает пользоваться помощью форумов и готовыми решениями.
У меня нет ни статистики, ни опыта в плане оценки скорости выполнения запроса для mysql для таблицы, скажем с 10000 строк описанного в первом посте.
И для удаления избыточности тоже нет время, т.к. существующая структура БД достаточно сложна.

Кстати, теория говорит еще вот что:

"В теории баз данных говорится о том, что схема базы данных должна быть полностью нормализована. При работе с полностью нормализованными базами данных необходимо применять весьма сложные SQL-запросы, что приводит к обратному эффекту - замедлению работы базы данных. Поэтому иногда для упрощения запросов даже прибегают к обратной процедуре - денормализации."

И по поводу других решений - так уж и не бывает? Это сверхзадача, распарсить строчку текста? Другое дело, что производительность, например, пострадает.

 

[Фанат]

если это не сверхзадача, то почему бы тебе не решить её самостоятельно?

 

[akd]

karlos, для того чтобы начинать думать о денормализации, нужно научиться приводить базу в нормальное состояние и понимать как работают "весьма сложные SQL-запросы".

 

[karlos]

*****: php это не под силу?

akd: : к счастью, жизнь пока не вынуждает меня полностью изучать/оптимизировать/нормализировать чужую БД состоящую из 101 таблицы.

Изначально я интересовался просто принципиальной возможностью осуществить задуманное силами mysql и php так, как я задумал.

И у меня, наверное, нет причин не верить гуру, которые говорят, что это невозможно. Спасибо за консультацию, буду пробовать!

 

[akd]

karlos, это возможно, но обьяснять тебе как это сделать никто не будет, ибо "ты не должен этого хотеть".

как сделать правильно тебе Wicked в первом ответе подсказал.

 

[karlos]

да понял я все
просто ожидал услышать здесь хоть какую-то аргументацию такого выбора, помимо того, что "так надо"

 

[akd]

аргументации ему захотелось.

ну ты ведь не хранишь пользователей в одной строке в виде 'вася пупкин, 1971-01-24, пользователь, очень умный, траляля, что-то еще, москва'? а почему не хранишь? вот поэтому и города так не стоит хранить.

а "так надо" - это правило. тут как, например, в фотографии. ты можешь нарушать правила но надо понимать зачем ты это делаешь и что хочешь получить благодаря этому нарушению.

 

[Wicked]

karlos
аргументация вида "если ты так сделаешь, то сможешь сделать то, что задумал, к тому же сделать это правильно" тебе не нравится?

 

[karlos]

ну все - накинулись скопом, вам только палец в рот положи!

я б и не хранил, только приложение-то готовое и мне было неясно, что проще - добавить несколько доп. полей либо извратиться и выдрать слова со строк. Считай, убедили

-~{}~ 19.11.07 13:37:

Снова добрый день всем присутствующим.
Собственно, вняв справедливым доводам знающих людей, добавил несколько доп. полей в БД, дабы облегчить выборку уникальных значений.
А просьба теперь такая, как можно вытащить запросом уникальные значения полей user_from, user_from1, user_from2 в одну колонку?
Т.е. то, что для одной колонки реализуется таким запросом:

SELECT user_from, COUNT( * ) AS count
FROM phpbb_users
GROUP BY user_from
ORDER BY `user_from` ASC

Если религия вам не позволяет показать готовый запрос, буду рад и ссылке, где описывается синтаксис подобного запроса.
Спасибо!

 

[Фанат]

странно.
вроде бы, советовали не это.
советовали сделать две таблицы.
первая - с городами.
вторая - со связями город-юзер.