[Sirin]

Сообщение от Январь

Вот как-то так - по этому пути пошел я...

Ну и?..

[Январь]

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

Ну и?..

И решил, что убить еще один проект - смысла нет в общем-то, по этому функционал будет включен в состав соц.сети...

...

Пример по выше написанному:

Допустим есть некоторая абстрактная книга "Шу и вайтмары". У нее уникальный альяс = Шу. У нее есть 3 главы: г.1, г.2, г.3. Вторая глава имеет содержательную часть.

В базе это выглядит так:

(id, alias, level, lkey, rkey)

1, Шу, 0, 1, 8
2, Г1, 1, 2, 3
3, Г2, 1, 4, 5
4, Г3, 1, 6, 7

Плюс вторая глава имеет содержательную часть:

<context>
<p>Шу</p>
<p>Еж</p>
<p>Пыш</p>
<p>Винни</p>
</context>

...

Допустим кторо вводит "Шу.2.3".

По первому индексу (Шу) мы можем получить точное указание на головной узел (узел с id = 1), а все последующие индексы являются по сути смещениями.

И так, мы получили указание на узел:

1, Шу, 0, 1, 8

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

И так - ищем второй дочерний элемент по отношению к головному: мы точно знаем, что если уровень (level) головного = 0, то уровень его дочерних равен 0 + 1, то есть выбираем только из элементов с level = 1. Получаем 3 элемента. Нужен второй. Лимитами второй элемент получается элементарно.

И так общее правило - level = root.level + 1, lkey > root.lkey, rkey < root.lkey, limit index - 1, 1, при порядке сортировки по левому ключу...

То же самое верно для поиска третьего индекса, четвертого, пятого и всех остальных...

И так мы нашли элемент:

3, Г2, 1, 4, 5

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

В случае запроса "Шу.2.3.2" - получим "ы". В случае запроса "Шу" - получим дерево глав. В случае запроса "Шу.2" - получим все содержание второй главы.

... ... ...

На практике - прилетел запрос: "Шу.2.3" - разбиваем го на секции:

PHP код:

$request = 'Шу.2.3';
$section = explode ('.', $request); 


Нулевая секция - это всегда уникальный альяс книги, по этому ищем корневой узел этой книги:

PHP код:

$some_database_controller -> query ('

SELECT *
FROM `table_name`
WHERE `name` = "'.$section[0].'"

;'); 


Дополняем запрос так, чтобы одним запросом получить и второй узел (дочерний):

PHP код:

$some_database_controller -> query ('

SELECT 

`level1`.*

FROM `table_name` `root`

LEFT JOIN `table_name` `level1`
ON `level1`.`level` = `root`.`level` + 1 AND `level1`.`lkey` > `root`.`lkey` AND `level1`.`rkey` < `root`.`rkey`

WHERE `name` = "'.$section[0].'"

ORDER BY `level1`.`lkey`

LIMIT '.($section[1] - 1).', 1

;'); 


И так мы нашли вторую главу...

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

Так что... Но это по ситуации надо уже смотреть...

[Шуня]

Всего-то ничего делов

[aunique]

Январь, ты что предлагаешь всё в одной таблице хранить?

[Январь]

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

Январь, ты что предлагаешь всё в одной таблице хранить?

Нет... Структуры и содержания в одной - это понадобится для полнотекстовой индексации... А смежные данные в других каталогизаторных таблицах...

Разумеется...

Содержания конечно можно было бы вынести и в другие таблицы... Но - это доп. груз при поисковых запросах - соответственно вместо 1 полнотекстового поиска в поисковом запросе будет использовано минимум 2, а может и 3, а может и 4... Так что - проще в одной таблице хранить...

И да...

Тут еще забыли про вопрос длинны полей. Главу МВ не в каждый TEXT еще засунуть получится... Так что придется отталкиваться от LONGTEXT, но и он может не все обусловит...

Тут такое дело - в любом случае понадобится единый формат хранения, но - а как проводить поиск например по данным в формате XML??? И, но если в XML хранить 1 параграф, то длинна записи автоматом увеличивается на 7 единиц - и это не считая стилизации (прочей)... То есть - на выходе можно таки получить текст, чья длинна увеличена в 1.5-2-3 раза относительно полезного содержания. И опять же - как это индексировать? Хранить аналоги? Тогда как хранить таблицы, как выделять сноски?

Так что - решайте...

Я то - хо хо хо!!!

[Sirin]

Решайте - кто?

Кто у нас тут айтишник с ааафигенной зарплатой, я или ты?!

Я на пальцах могу объяснить, чего надо. ТЗ называется.
А чё как индексировать - это ты решай.

[aunique]

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

Решайте - кто?

Кто у нас тут айтишник с ааафигенной зарплатой, я или ты?!

Я на пальцах могу объяснить, чего надо. ТЗ называется.
А чё как индексировать - это ты решай.

Таблицы и сноски хранить в полях с типом Blob + добавить ещё одно поле(ТипБлобов) в котором будет информация - какого типа данные хранятся в блоб: 1-текст(сноска) 2- картинка(формула).

[Sirin]

Январь в запой ушёл, как понял, что работа наклёвывается...

[aunique]

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

Январь в запой ушёл, как понял, что работа наклёвывается...

А не проще ли нам из каждого fb2 сваять html и связать их все в сайт. А поиском будет заниматься Яндекс, Гугл и другие страшные аббревиатуры.
Это мы и сами легко сделаем.