Разъясните господа. Я правильно понял, что UNIMARC предписывает хранить библиографическую запись в виде "сосиски" с разделителями полей?
Ведь в реляционной базе это не удобно в целях поиска и определния структуры базы, если речь идет о собственной разработке. Неудобно искать и отбирать записи. Не будешь же выбирать запросом "... WHERE BibZap LIKE '$aИванов' " и т.д. Да и размер поля не определишь. С другой стороны требования и стандарты почему-то часто меняются, вдруг какие-нибудь поля еще добавятся.
Получается замкнутый круг: одной большой "сосиской" хранить неудобно, а разными полями не перспективно.

Что делать, как говориться?

Этот вопрос равносилен тому, как если бы человек, впервые увидевший компьютер, спросил: "Ребята, какие кнопки тут надо нажимать для того, чтобы создать систему автоматизации библиотек?"

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

Как раз наоборот, все умеют программисты! Незачем так опускать народ.
У меня сначала в базе была такая структура. Сущность наименование (автор, название и т.д.) связывалась в отношении один ко многим с сущностью издание (издание, издательство, год издание и т.д. все, что касается конкретного издания книги), и уже издание связывалось отношением один ко многим с сущностью экземпляр.
Но как показала практика, в нашей библиотеки, редко какое наименование имеет больше одного издания. Лишь иногда два и более. Поэтому думаю, зачем огород городить из связных таблиц, когда больше времени будет уходить на связывание таблиц в запросе. Сейчас сделал без наименования, в сущность издание добавил все поля из наименования.
Вот и спрашиваю у продвинутых людей может кто знает как лучше, понятно, что и так и так можно.

Зачем говорить, что люди думаю все в одну таблицу пихать. У меня сейчас в базе уже более 30 таблиц, а более полная модель на бумаге имеет более 50. По понятным причинам хочется оптимизировать структуру, чтобы не выполнять лишних запросов! А вы говорите, программисты не умеют...

З.Ы. Читать книги для библиотекарей,чтобы формализовать предметную область, - скучно, тем более в них толком ничего не написано, а для технического ума ничего нет.

я сказал либо, потомучто сам видел таких, ко всем конечно не относиться, ведь есть в разных областях люди, которые считают себя квалифицированными, а на самом деле таковыми не являются.
Что касаемо вашего случая, вам решать как делать, но например у одного автора может быть много наименований например, также наименования могут быть одинаковыми, и заглавия могут быть построены по такому же признаку (есть такое понятие, как авторитетная база заглавий (авторов и пр.)) поэтому рациональнее использовать сложную структуру БД со связями, к стати продолжающихся заглавий не так уж много, в ВУЗе при 30000 записей, продолжающихся заглавий около 500, получается одно и тоже написано 60 раз
какая разница одна таблица или 30 если у них нет связей?
отсюда вывод, необходимо оценить соотношение: затраты - полученный эффект (цена- качество)
к стати разработчики АБИС объясняют то, что поиск по сложной базе данных происходит медленнее, чем по отдельным таблицам (поисковым), что на самом деле верно, но спорно.
про таблицы, в программе БИБЛИОТЕКА 4.02 их тоже куча: сама база и поисковые таюлицы, причем база разбита тоже на несколько, но отнюдь не по полям, а по какомуто другому признаку, помоему по длинне записи.

спасибо за рассуждения...