Ой, а как-же это сделать-то?

[Alexey]

Да, не всегда полная нормализация ди 3-й НФ имеет смысл, это так. Однако в данном случае, я так понимаю, что одному полю задали массив значений, т.е. множественное значение для данного атрибута. При этом вместо использования первичных/вторичных ключей, использующих индексирование и очень-очень быстрый поиск, приходится использовать в тысячи раз более медленные строковые алгоритмы. Я не знаю в каком месте они ТАК достигли быстродействия.

[Йода]

Сообщение от ubuntu

select * from `таблица` where LOCATE('|59|', '|'+`поле`+'|') > 0

это фултекстсёрч.
ну нельзя же так, вы чо?
это можно врагам такую идейку подкинуть.

Сообщение от Alexey

разработчик видимо не удосужился

он не разработчег. он дебил.


Добавлено через 1 минуту

Сообщение от Alexey

не всегда полная нормализация ди 3-й НФ имеет смысл, это так. Однако в данном случае, я так понимаю, что одному полю задали массив значений, т.е. множественное значение для данного атрибута. При этом вместо использования первичных/вторичных ключей, использующих индексирование и очень-очень быстрый поиск, приходится использовать в тысячи раз более медленные строковые алгоритмы. Я не знаю в каком месте они ТАК достигли быстродействия.

абсолютно так.

[boric]

Jooz,

В ячейке лежать идентификаторы, с которыми надо бы поработать, примерно так:

62|63|59|101|91
62|66|59|102|97|16
59
13|12|102

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

Хотя нет. Посмотрел на цифры - это не похоже на то, что я написал выше. Это не дерево.

[Йода]

Сообщение от boric

Если так, то разработчик всё нормально сделал

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

[boric]

Йода,

Нифига. Предпосылки не важны.
Важно то, что числа, по которым может идти поиск лежат мало того что в текстовом поле, так еще и в свалке, которую надо парсить.

Я выше добавил, что к сабжевому случаю мои комменты не относятся, т.к. там не дерево.

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

Например мы получили доступ к узлу id=78. У него поле parent_ids="1,23,78".
Теперь чтобы получить например всех родителей этого узла, достаточно одного запроса:
select * from nodes where node_id in (1,23,78)
где 1,23,78 - это parent_ids текущего узла, т.е. запрос очень простой и он один и быстрый.

Если требуется получить все подузлы, то тоже достаточно одного быстрого запроса:
select * from nodes where parent_ids like "1,23,78,%"
где "1,23,78,%" легко получается из parent_ids текущего узла.

А вот при обходе ветви дерева дергать всех родителей или потомков (как это делается в большинстве движков) - это извращение. Потом появляется сотня запросов на страницу.

[Йода]

Сообщение от boric

хранение цепочки идентификаторов родителей узла в строке - это стандартное решение

Я не спорю. Тока ведь то что привычно- оно не всегда прально..

А оптимизировать нужно всегда. Ибо щас оно маленькое- а ну как вырастет? Или чонить другое на этом движке забахают? А неоптимальность в таких делах- это хостинговое бабло, как ни крути..

[boric]

Йода,

А оптимизировать нужно всегда. Ибо щас оно маленькое- а ну как вырастет? Или чонить другое на этом движке забахают? А неоптимальность в таких делах- это хостинговое бабло, как ни крути..

Ну, в данном примере прежде всего все может упереться в длину строки. Идентификаторы в mysql теоретически могут быть достаточно большими (вроде до 20 разрядов), длину строкового поля особо длинным тоже не стоит делать, т.к. индекс работает вроде не более чем по первым 1024 байтам строки. Но мне например десятка уровней вложенности вполне достаточно, даже с запасом. В любом случае вынести когда приспичит в отдельную таблицу не проблема. Я в своем движке тоже планирую вынести в отдельную таблицу - всё же идеологически правильней конечно id хранить как целые числа, но с другой стороны придется делать дополнительный запрос или джоин, да и нет необходимости пока.

[Йода]

Сообщение от boric

Ну, в данном примере прежде всего все может упереться

Хорошо. Уговорили.
Вам можно.

[Jooz]

Сообщение от Йода

он не разработчег. он дебил.

Именно.
А дело обстояло так:
Небольшая компания где-то в 90-тых наковыряла программиста, который в бародатых годах написал программку (программист вероятно уже умер от икоты) на FOXPRO. Суть программки не важна, важно то, что структура программы подразумевает отношение один ко многим, вот это так и реализовано - в отдельном поле ID отношений (категорий др. словами). Как этот чудо программист это разруливал на FOXPRO ума не приложу - код реально не читаемый, т.к. самая длинная переменная из двух букв ))), в прочем как и таблицы со столбцами - нейминг мозг выносит напрочь. В общем мне в работу попали тупо DBF-ки, архитектурно я их победил - понял что к чему, а вот связь 1 ко многим тормознула меня почти на сутки, самое обидное что я поторопился и даже уже сделал web-интерфейс добавления инфы, со всякими аяксами и прочими вкусностями (так требует заказчик), а когда добрался до вывода отчетов - ужаснулся, даже не мог себе предположить что упущу такой момент косячный - в общем на ошибках учатся - потерял 18 часов на переделку

Сейчас уже все разобрано и функционирует.

[shadx]

Андрей Барыкин, маладес.

У мну например есть БД, в ней 60К товаров (парс Я.Маркета). У каждого товара есть описание состоящее из поле + значение. Для одного товара, таких полей может быть от 10 до сотни. Если хранить описания в тупую = одна строка в таблице |айди товара|айди поля|значение, то записей в таблице становится больше пары мульенов. Все баста мускул повесился. А если такую запись свернуть к строке {айди поля;значение|айди поля;значение|...} то все живет и радуется. НО!!! по описаниям никакого поиска не производится только красиво выводится пользователю.

А так ИМХО проще таблицу разбить, скриптом и по новой уже поискать (эт если единоразово), если надо постоянно, то хз даж че предложить все варианты не очень.