Почему разработчики программы изначально не стали пользоваться БД SQL, Оракл или др.???
Загрузка БД ИРБИС по сети енто "мучение" ... если же сеть свободна (енто бывает в основном утром) то ждать окончание загрузки практически не приходится, но днем ... В то время как, пользуясь БД SQL у меня ентой проблемы не возникает, что утром, что днем, что вечером ... скорость обработки данных и их загрузка измеряется от 0,008 до нескольких секунд ...

А Вы знаете, что такое структуры данных?
Библиографические данные - это иерархическая или объектная модели. А Вы предлагаете изначально взять умирающую реляционную.

Когда ИРБИС разрабатывался, тогда еще Oracle и в помине не замышлялся. Тогда только-только появился dbase.

А почему бы не сделать сервер БД?

Как Вы говорите "умирающая реляционная" еще долго будет жить ... к стати, чем она Вам не нравится?

Дело в том, что начиная с SQL-99 она уже объектно-реляционная. А вопрос Вы задавали именно из соображений структуры данных.
Скорость работы со структурированными данными в СУБД реляционного типа оптимизирована именно для задач таблиц. Библиографические данные – это неструктурированные данные (или слабоструктурированные). Попытки использования SQL для них сводятся лишь к использованию BLOB в качестве единого поля. А разбор данных из BLOB (составляющих) конкретной биб.записи осуществляется программным обеспечением клиента. И если для таких систем приходится самостоятельно писать побитный разбор таких записей из BLOB, то в CDS/ISIS все это заложено на низком уровне. А то, что нет клиент-серверной структуры в ИРБИСе-32, так для этого есть Java-ISIS.
ИРБИС-64 имеет клиент-серверную структуру, но модель данных там иерархическая, а не реляционная.

Огромная просьба, почитайте историю развития информационных систем. Почитайте про Jasmine, Adabas, CDS/ISIS, Goods и прочие. Ну негоже мне рассказывать, что для езды по лесу нужно покупать джип, а не Ferrari. Библиографические данные имеют специфическую структуру (модель данных).

Спасибо за исчерпывающий ответ ...

А почему "Библиографические данные – это неструктурированные данные (или слабоструктурированные)"? В чём сложность? Спрашиваю т.к. с моей точки зрения структурированию эта информация вполне поддаётся. Может конечно я не вижу какого-нибудь узкого места.

Как мне кажется Александр Сергеевич имел виду, что набор полей для каждого издания или электронного ресурса может быть своим и выделить все поля для всех возможных вариантов сложно. В CDS-ISIS набор полей переменный, чего нельзя сказать о РСУБД. Даже если Вы выделите ВСЕ возможные поля для ВСЕХ видов документов, которые присутствуют в природе или которые Вы собираетесь описывать, то база получиться не просто большой, а огромной, да и избыточности в ней будет в достатке :).
Это мое мнение.



Отправка отредактированного (30-08-04 17:50)

г. Ярославль

Все, что написал Максим выше - согласен на 100%.
И еще. За все время существования библиографических данных они меняются.
Возьмите первый том книги "РУСМАРК в примерах", потом второй. А ведь еще не описаны цифровые коллекции, коллекции коллекций с требуемой пользователю детализацией (и даже этот термин еще требует объяснения). И так далее. Т.е. при "стабильной" (структурированной) моделе данных Вы как программист будете постоянно что-то в своей программе править и, именно, на уровне заложенной модели, т.е. прописывать новые поля и многоуровневые связи. При работе с другими моделями Вы будете только править связи и алгоритмы их обработки.
Вот и все.

А позвольте снова не согласится.
Совсем не обязательно, вносить ВСЕ поля в структуру, достаточно сделать это для основных, остальные можно подключать по мере необходимости и совсем было бессмысленно валить все в одну таблицу (это к вопросу об избыточности). А чтобы не править бесконечно достаточно сделать довольно гибкую модель, позволяющую пользователям самим достраивать, то чего им не хватает.
Про гигантские размеры также не согласен, есть такой тип данных VARCHAR который хранить только реальные данные, и если поле объявленное длинной 1000 символов не заполнено, то физически под него выделится только место для указания что поле пустое, а но все 1000 байт.
В общем все как всегда упирается в разработчиков.

А теперь не соглашусь уже я :)

"...Совсем не обязательно, вносить ВСЕ поля в структуру, достаточно сделать это для основных, остальные можно подключать по мере необходимости и совсем было бессмысленно валить все в одну таблицу (это к вопросу об избыточности)..."
Подключать по мере необходимости КУДА? Добавлять в базу? Тогда в какую таблицу? Если еще и таблицы создавать тематические, то кто буедт следить за связями? Администратор? Не файк, что он разбереться в базе не хуже разработчиков, в может понадобиться добавить быстро, тогда-то и возникнет каша.
А причем здесь одна таблица и избыточность? Избыточность легко создать и с помощью нескольких таблиц. Если делить все на много-много справочников, то тогда на одних ссылках на них место теряется :)...да и могу дать 100%, что избыточность будет, без нее никуда. Я делал базу в 60 таблиц и всеравно полностью свести на "нет" избыточность у меня не получилось :(. А в библиографической базе может еще и больше таблиц.

"...А чтобы не править бесконечно достаточно сделать довольно гибкую модель, позволяющую пользователям самим достраивать, то чего им не хватает...", сделайте гибкую систему на SQL и разбираться в ней даже программист будет не меньше 6 месяцев. А про достройку структуры пользователями я уже высказался.

"...есть такой тип данных VARCHAR который хранить только реальные данные, и если поле объявленное длинной 1000 символов не заполнено, то физически под него выделится только место для указания что поле пустое, а но все 1000 байт..."
Я, конечно не знаю всех СУБД, но вот с мнением по поводу варчар согласен. Этот тип - это тоже самое, что и чар. дело в том, что если поле 1000 символов, а забиты только 500, то при обращении к этому полю в результате вернется строка длинной 1000 символом, дополненная пробелами (для ЧАР) и 500 символов для ВАРЧАР. Я такую интерпретацию варчар слышал не от одного десятка людей. Может это и заблуждение, но такое мнение ходит, а дыма без огня не бывает.

"...В общем все как всегда упирается в разработчиков..."
Это единственное утверждение, с которым я согласен на 100% :)...

Ух как бурно :))) Даже молчать стало трудно

Mаксиму:
1. В isis мало избыточности?
Избыточность в данных: Ведь все данные текстовые. Так что, ipso facto. Понятно, конечно, что очень много зависит от разработчика. Но, к примеру, даже если огромное количество словарей используемых в ИРБИС привести к связи посредством кода (а не вставлять каждый раз всю строку Автора или Предметной рубрики, увеличивая файл документов, а потом использовать пакетную правку записей aka "корректировка по словарю"), все равно там где можно было бы обойтись 2 байтами, будет использоваться как минимум шесть.
2. Избыточность в структуре: необъятное не обымешь :), а за гибкость надо платить. И насчет "шести месяцев" - сильно сомневаюсь, что за те же шесть месяцев тот же программист разберется в структуре и всех связях гибкого ИРБИСа :) И добавление полей в isis ничуть не более простой процесс, нежели в таблицу. Так или иначе вы вынуждены будете это поле описать, и связи простроить и в форматах вывода обозначить. Эка проблема добавить поле в таблицу, если ни с чем его не связывать... А уж если вдруг не дай Бог, потерялся один единственный default.ws (вместе с его "правщиком"), вся ваша структура не более чем набор числовых меток и если они не коррелируются с известным и описанным форматом - она нема как сельдь в масле.
3. Насчет varchar. Величина хранимых данных и размер возвращаемой запросом строки вещи разные. Сколько заказал, столько и получил: и в isis точно также: строка будет забита нулями/пробелами если переменная оставляет такой резерв.

Я это не к тому, чтобы посрамить isis: сами то мы им вскормлены и даже периодически вспоены :). Но - скромно полагаю, что сама по себе структура великого преимущества не дает и, выражая солидарность с вышевысказывавшимися, "...все как всегда упирается в разработчиков..."

Уточнения:
1. Язык SQL и реляционные СУБД — не синонимы. Правда, SQL используется только в РСУБД, но не во всех.
2. Реляционная модель — это простая для понимания математическая абстракция, а иерархическая модель отражает структуру окружающего мира
· иерархические библиотечно-библиографические классификации (как и классификации наук) — модели мира; поэтому систематический каталог — «врата учености»
· по одному из определений термина «база данных», это «информационная модель предметной области», а каждая предметная область, естественно, иерархична (см. выше)
· процесс переработки информации в человеческом мозге имеет иерархический характер
· иерархическая архитектура свойственна ЭВМ, о чем говорят сами термины: центральный процессор, master, slave, периферия…
3. Как я уже писал, говорят, что иерархическая модель возродилась благодаря появлению XML. Ведь в ее основе, как и гипертекста, и HTML-XML, и даже мультимедиа одно и то же математическое понятие — граф.
4. С другой стороны, называть реляционную модель «умирающей» — это, пожалуй, слишком. По крайней мере, пока количественно РСУБД преобладают?
5. Библиографические БД являются слабоструктурированными еще и потому, что:
· качественный, полноценный ЭК должен содержать неструктурированные поля относительно большого объема: «Примечания о содержании», «Форматированное содержание», «Реферат», «Аннотация» и т. д. (не говоря уже о полных текстах)
· как здесь уже справедливо говорилось, структура библиографического описания (набор полей) сильно отличается в зависимости от вида документов, и если «ЭК представляет собой общую поливидовую Базу Данных» (как выражаются в ГПНТБ), то в целом его можно считать даже не структурированным (?)
· если пойти еще дальше, строго структурированными нужно считать только те поля, «которые принимают значения из некоторого конечного списка» (как выражаются в ГПНТБ) и которые вводятся из авторитетных файлов, словарей и т.д. )



Отправка отредактированного (08-10-04 17:22)

1)К вопросу об объёмах.
Я не знаю что для вас большая база. Для меня это база на пару гигабайт общим объёмом, содержащая в себе минимум 200-300 таблиц плюс процедуры и т.д. т.п., ну и основная таблица содержит минимум 1 млн. записей, вот это я скажу нормальная средненькая база. Поэтому слова об экономии 2-3 байт на запись не очень уместны.

И про "пакетную правку записей aka "корректировка по словарю" по словарю я не очень понял.

2)Под пустой varchar(1000) будет зарезервировано только порядка 12 байт, а может и меньше сейчас не помню, да и зависит от реализации сервера. Место под нее не резервируется, по мере необходимости выделяются новые блоки.
3) Неструктурированные поля прекрасно ложаться в Blob(Text), который имеет практически не огранниченный объём. Кроме этого, например для Oracle существуют пакеты, для контекстного поиска и индексации таких полей.
4) Для гибкости самое простое 3 таблицы (Свойства, Значения свойств и Привязка значений к объектам), хотя количество может и возрасти для разнородный типов свойств.