Форум

Форум "Осознание" - Концепция Общественной Безопасности (http://forum.kob.su/index.php)
-   Конкретная работа. Предложения. (http://forum.kob.su/forumdisplay.php?f=6)
-   -   Полная база работ авторского коллектива ВП СССР (и сопутствующих) (http://forum.kob.su/showthread.php?t=4452)

Январь 30.05.2012 13:00

Цитата:

Где-то у меня были FB2 конвертеры, по описанию супер-пупер.
В сети online-конвертеров 100500 штук полно...

http://ebook.online-convert.com/convert-to-fb2

Sirin 30.05.2012 13:19

По уму всё равно нужно руками допиливать. Сомневаюсь я сильно, что сноски, картинки и форматирование корректно может сохранить автоконвертер.
То, что лежит на dotu, почти всё сделано автоконвертером и требует допила.

В любом случае, множество работ уже нормально сконвертировано.
Вопрос состоит в создании полноценной индексированной БД.

aunique 30.05.2012 14:50

Цитата:

Сообщение от Sirin (Сообщение 87392)
По уму всё равно нужно руками допиливать. Сомневаюсь я сильно, что сноски, картинки и форматирование корректно может сохранить автоконвертер.
То, что лежит на dotu, почти всё сделано автоконвертером и требует допила.

В любом случае, множество работ уже нормально сконвертировано.
Вопрос состоит в создании полноценной индексированной БД.

Мы базу делаем под MySQL? Или как?
Январь правильно говорит, нужно определиться как мы будем брать данные из базы.
1. Это даст нам ответ на вопрос какая база нужна.
2. Рисуем базу, её таблицы, размерность, типы данных. Становится понятен формат данных и платформа для реализации.
3. Тогда форматируем fb2 под поставленные задачи.
4. Параллельно пишем запросы и обработку для заполнения базы.

Все согласны?

Январь 30.05.2012 16:32

Цитата:

Сообщение от aunique (Сообщение 87394)
Мы базу делаем под MySQL? Или как?
Январь правильно говорит, нужно определиться как мы будем брать данные из базы.
1. Это даст нам ответ на вопрос какая база нужна.
2. Рисуем базу, её таблицы, размерность, типы данных. Становится понятен формат данных и платформа для реализации.
3. Тогда форматируем fb2 под поставленные задачи.
4. Параллельно пишем запросы и обработку для заполнения базы.

Все согласны?

1. Определяем типы хранимых данных:

1.а - Структура книги
1.б - Содержательная часть
1.в - Смежные данные

Подробнее:

Структура книги - абсолютно все от регионального и муниципального деления государства, от политического устройства страны и до книги можно описать с помощью структуры. Соответственно если задумано обращаться к элементу по указателям вроде DW.3.12.45 - то хранилище должно быть структурированным. Но тут возникает вопрос - а что именно следует хранить и с какой степенью детализации? Очевидно, что первый индекс в примере (DW - Dead Water) должен быть указателем на книгу, вротой индекс на главу, третий на раздел, подраздел, секция, параграф и т.д. Таким образом приходит понимание одной вещи - одна и та же таблица для упрощения выборки при полнотекстовой индексации должна хранить как структуру, так и содержательную часть, как название глав, так и содержание глав. Но хранение данных по параграфам - это слишком емко, по этому очевидно, что при степени детализации "параграф" заводить под каждую отдельную единицу новую запись - себе дороже, значит нужен общий парсер, способный рассчитать нумерации параграфов (или блоков в целом - параграфов, инсетов, таблиц, формул) для каждой главы (объемлющего хранилища)...

Вот это - принципиальная и наиболее сложная вещь по контексту замысла.

Ну а смежные данные - тут просто - это рубрикатор, категории, каталог событий, даты, теги и пр. и пр. и пр.

Решение:

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

Это главное, а дальше проще:

Если некто ищет скажем: DW.5.17.19.3 - то по первому индексу мы находим книгу, а зная головной (топовый) элемент таблицы мы от него можем получить полное дерево (структуры) этой книги. Далее также никаких особых геморроев нет - если мы знаем топовый элемент, то получаем элемент второго уровня с индексом 5, из его ветки получаем элемент третьего уровня с индексом 17, из его ветки получаем элемент с индексом 19 и т.д.

То есть - все просто.

Далее - допустим у нас элемент 4 уровня с индексом 19 является содержательной частью. Значит нам надо найти в ней параграф №3 - как это сделать??? Еще проще??? Загодя для забивания книг в базу мы использовали редактор TinyMCE - он возвращает валидный хтмл, но при сохранении мы парсили его в промежуточный формат - наш личный XML... Когда перед нами встала задача найти третий параграф, мы читыем этот XML разбощиком и просто тупо берем узел "PARAGRAPH" с индексом 3... При желании мы можем и слово в параграфе найти - то есть тут проблем вообще 0...

...

Ну а смежники... Есть книга, у нее уникальный индекс DW и к ней пришиты доп.данные - категория = Социология, теги = ДОТУ, Заговор, Хомяки, авторы = ВП СССР, Январь ну и пр.

...

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

По вопросу сносок.

Я это вообще просто очень решил. Написал под TinyMCE плагин, добавляющий сноску. На место сноски он устанавливает спец.символ с номером сноски в рамках текущей объемлющей единицы структуры, а текст сноски записывает в реестр.

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

... ... ... ... ...

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

Sirin 30.05.2012 16:38

Цитата:

Сообщение от Январь (Сообщение 87398)
Вот как-то так - по этому пути пошел я...

Ну и?..

Январь 30.05.2012 17:10

Цитата:

Сообщение от Sirin (Сообщение 87400)
Ну и?..

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

...

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

Допустим есть некоторая абстрактная книга "Шу и вайтмары". У нее уникальный альяс = Шу. У нее есть 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


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

Код HTML:

<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 точно вычислить узел пробежкой по массиву.

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

Шуня 30.05.2012 20:37

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

aunique 30.05.2012 20:50

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

Январь 30.05.2012 21:25

Цитата:

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

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

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

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

И да...

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

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

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

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

Sirin 31.05.2012 01:30

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

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

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


Часовой пояс GMT +3, время: 02:24.

Осознание, 2008-2016