LINUX.ORG.RU

«Автоматизаторы отечественных библиотек - объединяйтесь !» или о разработке свободной АИБС


0

1

Всем привет. Я подрабатываю на полставки программистом в областной библиотеке г.Кирова (Кировская область).
Головная боль нашего отдела (занимающегося компьютерами и программами) - это АИБС "Марк-SQL".
"Марк-SQL" установлена во множестве библиотек России (в том числе в сельских и школьных).
На более дорогую систему у нас не хватает денег - а эта система "в целом" нас устраивает.
"В целом", потому что:
1. Разработчики НПО "Информ-Система" выпускают достаточно сырой продукт - приходится каждый год покупать новые версии, чтобы угнаться за потребностями некоторых отделов библиотеки.
2. Нет версии под Линукс - это основная проблема, мешающая перейти библиотеке на свободное ПО. Замена остальным программам найдена.
3. Эта информационно-библиографическая система привязана к MS SQL Server / Oracle, а это - сотни тысяч рублей от каждой крупной библиотеки.

Другими словами, идея состоит в том, чтобы сэкономить время, нервы и деньги библиотек, разработав свободную информационно-библиографическую систему.

Я начал писать клиентскую часть на C++ с использованием графической библиотеки FOX Toolkit (LGPL).
Разобрал формат, в котором хранит данные Марк-SQL.
Сейчас думаю над тем, какую СУБД использовать для начала. Возможно - SQLite.

Кто желает присоединиться к процессу разработки, написать отзыв о какой-либо существующей библиотечной системе, или может порекомендовать знакомых, работающих в библиотеках - пишите сюда или на Jabber: pacify@jabber.ttn.ru.

★★★★★

>Сейчас думаю над тем, какую СУБД использовать для начала. Возможно - SQLite.

ну если они юзают MS SQL Server / Oracle то почему бы тебе не использовать postgresql ? или SQLite вполне хватит (тогда зачем там эти монстры ?)

anonizmus
()
Ответ на: комментарий от anonizmus

Пока я решил попробовать MySQL - там есть поддержка XML + XPath (нужно для эмуляции иерархической СУБД).
Причина - каждая библиографическая запись формата RUSMARC/MARC21 в теории может иметь до нескольких сотен атрибутов (полей), и хранить в классической реляционной СУБД их нерационально.
А придумывать свой велосипед для структурированных текстовых данных лень. XML, думаю, подойдет.

pacify ★★★★★
() автор топика
Ответ на: комментарий от pacify

>Причина - каждая библиографическая запись формата RUSMARC/MARC21 в теории может иметь до нескольких сотен атрибутов (полей), и хранить в классической реляционной СУБД их нерационально.

А хранить в X.500? Конечно Apache Directory Server еще сырой, но ооочень перспективный. Или на худой конец Novell eDirectory, хоть платный, но черт с этим.

Тем более, что библиографические данные как раз часто запрашиваются, и редко изменяются...

Macil ★★★★★
()

А зачем в таком абсолютно прикладном приложении C++ ? Или вы других языков не знаете :) ?

А может ее сразу делать с вебинтерфейсом ? А то вы наверное и архитектуру этого МАРК хотите скопировать ? А ведь писали его в то
время когда слово БД значило программа на фокспро :) И в некоторых случаях на дельфи :p

Чего нибудь вроде perl/python должно вполне хватить, я просто не очень верю что в каком нибудь российской библиотеке такое большое количество запросов в секунду что оправдано применения таких средств как C++. Там все таки наверное идет речь о запросах в минуту :)

kernel ★★☆
()
Ответ на: комментарий от kernel

Просто вначале я хотел делать ее закрытой, коммерческой - вот и начал на C++/FOX.
Но мы, видимо, напишем ее на Python+Qt4. С базой пока окончательно не определся - надо подбирать.

pacify ★★★★★
() автор топика
Ответ на: комментарий от pacify

ИМХО под питоном все нормально было с коммерческой разработкой - лицензия позволяет. Чтобы исходников небыло видно можно только байткод оставлять в дистрибутиве.

И кстати - а что не вебинтерфейс ? django + жабаскрипт и вперед :)

kernel ★★☆
()
Ответ на: комментарий от pacify

>Но мы, видимо, напишем ее на Python+Qt4.

Очень сильно советую посмотреть в сторону явы. Очень. В сторону GUI дизайнера в NetBeans. А также в сторону какого-то IoC фреймворка. И вообще, очень тебе советую реализовать в виде веб-проложения. Тебе же проще в конечном итоге, заодно и идиому MVC асилишь.

С базой, еще раз говорю, посмотри в сторону X.500, не OpenLDAP а X.500. К сожалению, в его концепции работы придется разбираться, но по крайне мере можешь к нему относиться как к XML файлу, к которому ты обращаешься с помощью XPath.

ЗЫ: Я сам питонщик со стажем...

Macil ★★★★★
()
Ответ на: комментарий от Macil

>>не OpenLDAP а X.500

Офигеть - сравнивать одну из реализаций со спецификацией протокола.

И чем же DAP лучше LDAP (одна из реализаций которого имеет приставку Open)? Тем что тяжелее?

anonymous
()
Ответ на: комментарий от pacify

Хм...не советую использовать Qt ибо за нее надо деньги платить если хотите писать коммерческий софт.

Virun
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.