А кстати не кто не в курсе а git какую БД использует?

> Также хочется хранить стили оформления отдельно от содиржимого.

Даже не думай об этом, если планируешь совместную работу над документом людей, которым все эти иксыимэли глубоко до фени.

есть такой визуальный редактор для CMS, называется WYSIWYM (или просто WYM). Там это работает :)

> А кстати не кто не в курсе а git какую БД использует?

файловую систему + папочку .git с настройками в корне репозитория. Это самая главная фича ;) Например, если что-то случится с репой SVN, то так просто ее уже не восстановишь.

> В программе требуется обрабатывать (парсить) большие тексты, а также иметь возможность экспорта/импорта в форматы TeX, otd, rtf, pdf.

XML же!

А что если создать систему аналог git на реляционной БД, которая будет хранить мета информацию документов?

или просто WYM

Знаем пользовались ;) Вот и думаю, что то подобное намутить, но для других целей.

> А что если создать систему аналог git на реляционной БД, которая будет хранить мета информацию документов?

Мы недавно думали про это, но насчет графического редактора. Но это работа не для одного человека. И, наверное, не для двух. Придется написать тысячи вещей. Кому еще кроме таких как мы экспериментаторов это интересно? Хоть один лоровец будет помогать возиться с написанием нового текстового или графического редактора? А с написанием новой VCS? Расстройство да и только.

Ну я могу подобрать толковых студентов. Это для них будет хорошая тема для диплома.

> http://en.wikipedia.org/wiki/EXist

написано на тормозной яве и главное — нет транзакций

хотя бы sedna

а вообще http://en.wikipedia.org/wiki/XML_database

> А что если создать систему аналог git на реляционной БД, которая будет хранить мета информацию документов?

а что этим можно добиться, кроме тормозов и перерасхода памяти?

Почему тормозов? Вот выше мне человек доказал обратное?

где доказал?

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

Я же хочу создать свой редактор и связать его с git (очень понравились идеи заложенные в нём) для распределённой работы

Tamino.

... но это если смотреть со строны vcs; а вот если основная операция будет «поиск по метаданным», то тогда вполне можно делать на основе БД, причем «повторение гита» вполне возможно сведется на выдирании оттуда алгоритма подсчета хэша ревизии и двух полях под «родительские» ревизии

http://www.softwareag.com/corporate/images/SAG_TaminoXML_FS_Jul09-web_tcm16-5...

Фсё уже придумано до вас

Вроде не совсем то.

> где доказал?

Читать вот здесь: (http://russian.joelonsoftware.com/Articles/BacktoBasics.html) со слов «На прошлой неделе я». Ну и вообще статья поучительная.

(Спольский, работал в команде старого Excel. И их Excel, черт возьми, самое быстрое десктопное приложение для работы с электронными таблицами.)

Как хорошо что он написал этот пост, теперь достаточно давать на него ссылку без дальнейших объяснений.

http://www.osp.ru/text/print/302/3776469.html Имхо это то что у тебя в итоге и получится


http://docbook.ru/index.htmlhttp://viju.tvercity.net/ru/articles/worddocbookh...

> Ну вот я тоже думаю XML или TeX.

В лисповских списках, я серьёзно.

Думаешь там profit больше, чем в реляционное БД, как советовали выше?

> Ну и вообще статья поучительная.

Поучительная? Треш. Статью можно смело закапывать. Нытьё про strlen соврешенно не актуально (посмотрите реализацию std::string; и не думаю, что в других языках со строками дела хуже, чем в c++). Про malloc там яростное 4.2 написано (оно было актуально лет 20 назад, наверное). Проблемы открытия переполненной корзины касаются исключительно любителей пофапать на NTFS. Про БД тоже очень наивные соображения.

А про высокую стоимость парсинга при компиляции - вообще ржака. Откуда этого идиота выпустили?

Есть, что почитать подтверждающие ваши доводы?

> Есть, что почитать подтверждающие ваши доводы?

Конкретно про компиляцию? Возьми какой-нибудь большой проект на с++, собери его сначала с -O0, а потом с -O2. И сравни время, учитывая, что парсинга в обоих случаях одно и то же количество ;)

Или про malloc? Вика говорит нам: Since the v2.3 release, the GNU C library (glibc) uses a modified ptmalloc2, which itself is based on dlmalloc v2.7.0. Про устройство этих аллокаторов найдешь сам, они совсем на такие дебильные, как в голове того вантузоида.

Про std::string? Отсылаю читать /usr/include/c++

ВНЕЗАПНО

как *.txt с отдельными файлами-описателями связей между документами.

Нет, я про «Про БД тоже очень наивные соображения. » спросил.

Извеняюсь забыл уточнить. =)