20.07.2011, 17:28 | #11 |
Мне повезёт!
Регистрация: 05.05.2007
Сообщений: 1,076
Вес репутации: 277
|
Да, не всегда полная нормализация ди 3-й НФ имеет смысл, это так. Однако в данном случае, я так понимаю, что одному полю задали массив значений, т.е. множественное значение для данного атрибута. При этом вместо использования первичных/вторичных ключей, использующих индексирование и очень-очень быстрый поиск, приходится использовать в тысячи раз более медленные строковые алгоритмы. Я не знаю в каком месте они ТАК достигли быстродействия.
__________________
If it's not great, it's not the end. |
20.07.2011, 23:01 | #12 | |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 417
|
это фултекстсёрч.
ну нельзя же так, вы чо? это можно врагам такую идейку подкинуть. он не разработчег. он дебил. Добавлено через 1 минуту Цитата:
__________________
Последний раз редактировалось Йода; 20.07.2011 в 23:01. Причина: Добавлено сообщение |
|
20.07.2011, 23:31 | #13 | |
Эксперт
Регистрация: 05.03.2008
Сообщений: 1,095
Вес репутации: 250
|
Jooz,
Цитата:
Хотя нет. Посмотрел на цифры - это не похоже на то, что я написал выше. Это не дерево. |
|
20.07.2011, 23:35 | #14 |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 417
|
Нифига. Предпосылки не важны.
Важно то, что числа, по которым может идти поиск лежат мало того что в текстовом поле, так еще и в свалке, которую надо парсить. Поэтому повторюсь- это не разработчик, это дебил, которому я и метеллического шарика бы не доверил- обязательно сломает.. ))
__________________
|
20.07.2011, 23:46 | #15 | |
Эксперт
Регистрация: 05.03.2008
Сообщений: 1,095
Вес репутации: 250
|
Йода,
Цитата:
Но если рассмотреть дерево, то хранение цепочки идентификаторов родителей узла в строке - это стандартное решение. Можно конечно вынести в отдельную таблицу, но на не очень больших наборах данных не всегда имеет смысл. Например мы получили доступ к узлу 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 текущего узла. А вот при обходе ветви дерева дергать всех родителей или потомков (как это делается в большинстве движков) - это извращение. Потом появляется сотня запросов на страницу. |
|
21.07.2011, 00:02 | #16 | |
Магистр
Регистрация: 04.12.2007
Сообщений: 3,680
Вес репутации: 417
|
Цитата:
А оптимизировать нужно всегда. Ибо щас оно маленькое- а ну как вырастет? Или чонить другое на этом движке забахают? А неоптимальность в таких делах- это хостинговое бабло, как ни крути..
__________________
|
|
21.07.2011, 00:45 | #17 | |
Эксперт
Регистрация: 05.03.2008
Сообщений: 1,095
Вес репутации: 250
|
Йода,
Цитата:
|
|
21.07.2011, 06:35 | #19 |
Вредина
Регистрация: 03.07.2007
Адрес: д.Коноплянка
Сообщений: 3,535
Вес репутации: 433
|
Именно.
А дело обстояло так: Небольшая компания где-то в 90-тых наковыряла программиста, который в бародатых годах написал программку (программист вероятно уже умер от икоты) на FOXPRO. Суть программки не важна, важно то, что структура программы подразумевает отношение один ко многим, вот это так и реализовано - в отдельном поле ID отношений (категорий др. словами). Как этот чудо программист это разруливал на FOXPRO ума не приложу - код реально не читаемый, т.к. самая длинная переменная из двух букв ))), в прочем как и таблицы со столбцами - нейминг мозг выносит напрочь. В общем мне в работу попали тупо DBF-ки, архитектурно я их победил - понял что к чему, а вот связь 1 ко многим тормознула меня почти на сутки, самое обидное что я поторопился и даже уже сделал web-интерфейс добавления инфы, со всякими аяксами и прочими вкусностями (так требует заказчик), а когда добрался до вывода отчетов - ужаснулся, даже не мог себе предположить что упущу такой момент косячный - в общем на ошибках учатся - потерял 18 часов на переделку Сейчас уже все разобрано и функционирует.
__________________
|
21.07.2011, 06:58 | #20 |
шайтанама
|
Андрей Барыкин, маладес.
У мну например есть БД, в ней 60К товаров (парс Я.Маркета). У каждого товара есть описание состоящее из поле + значение. Для одного товара, таких полей может быть от 10 до сотни. Если хранить описания в тупую = одна строка в таблице |айди товара|айди поля|значение, то записей в таблице становится больше пары мульенов. Все баста мускул повесился. А если такую запись свернуть к строке {айди поля;значение|айди поля;значение|...} то все живет и радуется. НО!!! по описаниям никакого поиска не производится только красиво выводится пользователю. А так ИМХО проще таблицу разбить, скриптом и по новой уже поискать (эт если единоразово), если надо постоянно, то хз даж че предложить все варианты не очень.
__________________
МордоКнига |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
как сделать? | voltol | Вопросы от новичков | 5 | 04.09.2010 14:43 |
Как это сделать? | Mrsined | Вопросы по работе системы | 5 | 27.08.2010 18:06 |
как сделать? | LATERMAUT | Вопросы от новичков | 12 | 28.10.2009 11:43 |
как сделать так...? | ncx | Курилка | 19 | 02.07.2009 16:30 |
Как так сделать??? | Socialka92 | Вопросы от новичков | 24 | 20.10.2008 01:02 |
Часовой пояс GMT +3, время: 08:12.