Ошибка рекламы «Здравмаг»!
Вернуться   Форум "Осознание" - Концепция Общественной Безопасности > Движение сторонников КОБ. Проекты. > Конкретная работа. Предложения.
ЗДРАВМАГ.РФ | МОЙ ПЛАКАТ | ТОРРЕНТ - ТРЕКЕР | ВСЕ РАБОТЫ ВП СССР
Проект "Оракул-Саул". Информация к размышлению.
Подробнее...

Конкретная работа. Предложения. Придумал - предложил - сделал.

Ответ
 
Опции темы Опции просмотра
Старый 31.01.2011, 17:40   #1
kont
Новый участник
 
Регистрация: 30.01.2015
Адрес: Земля
Поблагодарили 2 раз(а)
По умолчанию Полная база работ авторского коллектива ВП СССР (и сопутствующих)

Библиотека КОБ для Андроид


https://play.google.com/store/apps/details?id=com.yurikontik.cob_library.app


Apple:



https://itunes.apple.com/ru/app/biblioteka-kob/id850336250?mt=8
kont вне форума   Ответить с цитированием
Старый 30.05.2012, 13:00   #81
Январь
Команда сайта
 
Аватар для Январь
 
Регистрация: 14.05.2009
Адрес: Москва
Поблагодарили 1,604 раз(а)
Записей в дневнике: 3
Отправить сообщение для Январь с помощью ICQ
По умолчанию

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

http://ebook.online-convert.com/convert-to-fb2
Январь вне форума   Ответить с цитированием
Старый 30.05.2012, 13:19   #82
Sirin
Команда сайта
 
Аватар для Sirin
 
Регистрация: 21.10.2008
Адрес: Москва
Поблагодарили 8,920 раз(а)
Записей в дневнике: 129
По умолчанию

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

В любом случае, множество работ уже нормально сконвертировано.
Вопрос состоит в создании полноценной индексированной БД.
Sirin вне форума   Ответить с цитированием
Старый 30.05.2012, 14:50   #83
aunique
Местный
 
Аватар для aunique
 
Регистрация: 23.12.2009
Адрес: Алтайский край
Поблагодарили 140 раз(а)
Записей в дневнике: 20
Отправить сообщение для aunique с помощью ICQ Отправить сообщение для aunique с помощью Skype™
По умолчанию

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

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

Все согласны?
aunique вне форума   Ответить с цитированием
Сказал спасибо aunique за это сообщение:
Sirin (30.05.2012)
Старый 30.05.2012, 16:32   #84
Январь
Команда сайта
 
Аватар для Январь
 
Регистрация: 14.05.2009
Адрес: Москва
Поблагодарили 1,604 раз(а)
Записей в дневнике: 3
Отправить сообщение для Январь с помощью ICQ
По умолчанию

Цитата:
Сообщение от aunique Посмотреть сообщение
Мы базу делаем под 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)
Старый 30.05.2012, 16:38   #85
Sirin
Команда сайта
 
Аватар для Sirin
 
Регистрация: 21.10.2008
Адрес: Москва
Поблагодарили 8,920 раз(а)
Записей в дневнике: 129
По умолчанию

Цитата:
Сообщение от Январь Посмотреть сообщение
Вот как-то так - по этому пути пошел я...
Ну и?..
Sirin вне форума   Ответить с цитированием
Старый 30.05.2012, 17:10   #86
Январь
Команда сайта
 
Аватар для Январь
 
Регистрация: 14.05.2009
Адрес: Москва
Поблагодарили 1,604 раз(а)
Записей в дневнике: 3
Отправить сообщение для Январь с помощью ICQ
Post

Цитата:
Сообщение от 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


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

Код 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   #87
Шуня
Команда сайта
 
Аватар для Шуня
 
Регистрация: 21.09.2009
Адрес: С Бажен
Поблагодарили 451 раз(а)
По умолчанию

Всего-то ничего делов
Шуня вне форума   Ответить с цитированием
Старый 30.05.2012, 20:50   #88
aunique
Местный
 
Аватар для aunique
 
Регистрация: 23.12.2009
Адрес: Алтайский край
Поблагодарили 140 раз(а)
Записей в дневнике: 20
Отправить сообщение для aunique с помощью ICQ Отправить сообщение для aunique с помощью Skype™
По умолчанию

Январь, ты что предлагаешь всё в одной таблице хранить?
aunique вне форума   Ответить с цитированием
Старый 30.05.2012, 21:25   #89
Январь
Команда сайта
 
Аватар для Январь
 
Регистрация: 14.05.2009
Адрес: Москва
Поблагодарили 1,604 раз(а)
Записей в дневнике: 3
Отправить сообщение для Январь с помощью ICQ
По умолчанию

Цитата:
Сообщение от aunique Посмотреть сообщение
Январь, ты что предлагаешь всё в одной таблице хранить?
Нет... Структуры и содержания в одной - это понадобится для полнотекстовой индексации... А смежные данные в других каталогизаторных таблицах...

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

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

И да...

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

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

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

Я то - хо хо хо!!!
Январь вне форума   Ответить с цитированием
Старый 31.05.2012, 01:30   #90
Sirin
Команда сайта
 
Аватар для Sirin
 
Регистрация: 21.10.2008
Адрес: Москва
Поблагодарили 8,920 раз(а)
Записей в дневнике: 129
По умолчанию

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

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

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



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


Здравмаг.рф - магазин духовного и физического здоровья! Rambler's Top100