parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

"одноуровневый" -- читай скорее как 2-уровневый :)

sergei 15.06.2005 14:14

<adr>Маркса 666</adr>
<post-adr>Ленина 44</post-adr>
<adr>Энгельса 13</adr>

на такой структуре будет работать:
WHERE big_field like "%<%adr%>%Ленина%</%adr%>%"

Можно пользоваться и "нормальными регулярными выражениями" - я не спорю!

А при поиске по этому форуму используются ли "индексы в любом их проявлении"?

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

Под "исключениями" понимается отсутствие поиска по этим полям?

Теперь по поводу движка. Давайте разберём на конкретном примере.
Допустим есть интернет-магазин (берём упрощённую модель). Мы храним информацию о User-ах, сделавших заказ, о заказе, о составе заказа. Имеем в итоге 3 таблицы. Ну плюс таблица товары :)

Берем пока объект User.
У него есть набор свойств базовых:
- id
- nick
- password
- fio

и т.п.

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

в разных проектах даже в однотипных магазинах этот набор может меняться по малейшей прихоти заказчика.

Моя идея была запихивать эту инфу в одно поле.
Если честно, то я обмозговывал эту идею пока только для объекта User.

Будет ли производиться поиск по такому XML-полю?
ну иногда будет, если в системе управления заказами будет поиск, но обычно поиск делается глобальный, т.е. вводится:
"улица Энгельса"
хранится хоть как:
<adr>ул. Энгельса, д.1</adr>
<adr2>ул. Энгельса, д.1</adr2>
<my_adr>Энгельса, д.1</my_adr>

работает
WHERE .... or (big_field like "%улица%" or big_field like "%Энгельса%")

на самом деле таким образом реализованный полнотекстовый поиск даже удобнее реализовывать - при добавлении, удалении этих свойств не нужно будет править поисковый sql-запрос