|
|
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
В общем нужно сделать АИБС (автоматизированную библиотечно-информационную систему). Библиографические данные имеют ряд особенностей: а) Разнородная информация - статьи, книги, карты, атласы, периодика, многотомники,... б) Большое число полей, которые могут быть в количестве от 0 до бесконечность (теоретически) - есть специальные форматы для описания этих полей (симейство форматов MARC). Соответственно возникают некоторые проблемы с реализацией всего этого в реляционной базе - больое кол-во таблиц, полей, связей,... В коммерческих продуктов (MarcSQL, "Библиотека") используется несколько другой подход. Все поля библиографической записи храняться в одном поле типа Блоб. Запись сжимается, поля помечаются специальными тегами. Для поиска ведуться специальные таблицы с отношением многие ко многим с главной таблицей с записями (так называемые индексные таблицы, заполняются программно). Для отображения найденная запись расжимаеться, форматируется изображение. Итак, есть два подхода: 1) разложить по таблицам все поля. 2) все поля в одном поле. Хотелось бы подискутировать на эту тему - как лучще, может кто сталкивался. PS. Сделал по 2-му варианту, но из-за кривизны структуры постоянно чешуться руки переделать. PSS. SQL SERVER 2000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 14:59 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
AivenХотелось бы подискутировать на эту тему - как лучще, может кто сталкивался. Задача "дополнительной классификации" достаточно характерна; суть - к объекту добавляется некоторое количество "сугубо информационных" полей, этаких memo, не важных в контексте основных бизнес-процессов, но используемых для поиска и вывода информации пользователю. Для таких полей довольно естественными являются решения на основе тех или иных гибких форматов, скажем EAV или XML. Описанный Вами второй подход - примерно то же, но "велосипед собственными руками"; необходимости в нем особо не видно. Первый подход - с разложением по полям - также вполне применим, возможно в сочетании с ядром, позволяющим досоздавать в таблицах нужные поля. В принципе это более тяжелое, но и более мощное решение, позволяющее естественным образом использовать возможности РСУБД - скажем, делать такое поле внешним ключом. Соответственно, подход начинает выигрывать в тех случаях, когда функционирование приложения, бизнес-логика таки существенно завязаны на эти поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:15 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
авторОписанный Вами второй подход - примерно то же, но "велосипед собственными руками"; необходимости в нем особо не видно. Интересно, почему тогда коммерческие продукты пользуются этим подходом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:26 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
AivenИнтересно, почему тогда коммерческие продукты пользуются этим подходом? Гадать можно сколько угодно. Например, может быть потому, что во времена их создания в СУБД еще не было адекватных средств работы с XML. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:46 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
Библиография сто лет так работает. Так называемый конкорданс - типа индекс к виртуальным таблицам: Документ/Поле(тег)/Значение, Элемент документа(абзац, фраза)/Поле(тег)/Значение. Ну и специализированный поиск по конкордансу - слова в одной фразе, документе в целом и проч. Cравнение на больше-меньше - уже признак продвинутой системы:) Приблизительно конечно. Если пользоваться общепромышленными СУБД есть смысл посмотреть на Oracle Text. Тоже автоматизирует ведени подобных индексов по текстовым полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 15:55 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
авторНапример, может быть потому, что во времена их создания в СУБД еще не было адекватных средств работы с XML. Как тут можно прикрутить XML? Думаю если саму запись хранить в формате XML можно облегчить вывод на WEB страницу с помощью шаблона XST. Или еще что-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 16:16 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
> Так называемый конкорданс Как связаны конкорданс и каталогизация, можно поинтересоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 16:22 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 17:00 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
> Например И каким боком здесь каталогизация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 17:16 |
|
||
|
Структура БД для библиотеки. Как бы вы сделали?
|
|||
|---|---|---|---|
|
#18+
AivenКак тут можно прикрутить XML? Думаю если саму запись хранить в формате XML можно облегчить вывод на WEB страницу с помощью шаблона XST. Или еще что-то? Cаму запись - не стоит, а вот ее "гибкую необязательную часть" - почему бы и нет? Автоматом снимаются все вопросы по поводу форматов, множественных признаков итп, целостность проверяется xml схемой, для поиска по атрибутам проработаны технологии индексирования, вывод в интерфейс также несложно делается универсальным. Что еще нужно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2007, 17:51 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34408940&tid=1544668]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
160ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 473ms |

| 0 / 0 |
