Обсуждение

http://www.intersystems.com/cache/technology/techguide/index.html Знаю, что на этом медприложения бегают. Реляционка без администратора - это как-то ненадёжно.

Это совсем другого класса, мне нужно документацию генерировать, а не автоматизацию разворачивать. Поэтому мне нужно крутой генератор отчетов, скорость абсолютно неважна, пользовательский интерфейс важен, отсутствие деления на сервер и клиента важны (не хочу заводиться с поддержкой сервера) и т.д. Веб-приложения типа dabbledb.com в отличие от Access смогут работать для всех, а не только для меня. dabbledb.com -- не реляционная (написана, кстати, на smalltalk и очень хитро там устроена многоклиентская работа: каждому клиенту просто выдается виртуальная смоллток машина). Но меня даже не устройство волнует, а за сколько времени это хозяйство устанавливается, сколько времени я потом потрачу на вышивку отчетов, сколько времени займет поделиться этими отчетами с другими людьми. Dabbledb.com уже развернута в Сети, MS Access оказался установленным на моем ноутбуке -- это ближайшие кандидаты. А этот "кеш" слишком крут, с ним нужно отдельного администратора держать, и отдельного джава-разработчика.

Спасибо за dabbledb.com, infodome.com - ищу аналог экселя + одновременный многопользовательский доступ + схема + разграничение прав (по столбцам). Хотелось бы еще иметь возможность установить на своем железе, всё-таки большинство подобных сервисов далековато, и задержки в работе в режиме saas раздражают. Есть ли еще какие сайты подобного плана на примете? Заранее спасибо!

К сожаление ниже изложенное, не решает проблему поднятую в посте :(. Написанное выше больше похоже на систему управления полуструктурированными записями используемые в библиотечной каталогизации. Единица информации, хранимая в БД запись, содержимое может быть произвольным, атрибутика суть иерархия полей (на практике достаточно двух уровней вложенности поле/подполе, с указанием на повторяемость полей/подполей). Содержимое поля/подполя: произвольный текст, ссылка на другую запись, значение из плоского словаря (список значений или пар ключ/значение), значение из иерархического словаря. Словари могут быть связаны с записями. Структура БД строится из каталогов и схемы записи. Каталог сущность для выделения логической группы записей (в тексте выше "сводная таблица"). Схема это последовательность полей/подполей и их тип. Схема может меняться налету без опасений потерять данные, уже введенные значения в удаляемых полях/подполях записи остаются и могут удалится или переместиться в автоматическом или чаще в ручном режиме. Для редактирования схемы достаточно понимать, зачем вносятся изменения, само изменение достаточно тривиально. Отчеты строятся по выборкам записей из каталогов или путем группировки по значениям полей/подполей. Интерфейсное решение по вводу и редактированию в виде таблицы полей/подполей ориентировано на скорость работу с большим массивом информации. Но для не обученных операторов страшное зрелище, применять имеет смысл, только если число обрабатываемых записей больше сотен. ИМХО неспособность вложится в универсальный редактор записей (прежде всего интерфейсное решение) приводить к тому, что с Gellish удобно работать в режиме таблиц Excel. Интерфейс презентации сознательно отделяется от ввода и редактирования и может быть любым, основное требование скорость восприятия при работе с группами записей как целым (библиографические списки, и тп). Взять готовое решение, скорее всего не получится. Из готовых решений можно порекомендовать ИРБИС (http://irbis.gpntb.ru/). Сетевой сервис с возможностью изменения схемы мне не известен.

Я начинал работать с базами данных, когда они еще были деревянными, а также застал засилье ADABAS (CODASYL), потом освоил реляционные. Также понимаю, что сейчас есть постреляционные и базы данных из "движения NoSQL". Поэтому для меня ваш текст странен: вы пишете про какое-то странное подподподмножество баз данных. Сейчас все онлайновые базы хвастаются, что их схемы можно менять на лету, и предлагают инкрементальное построение этих схем (например, та же dabbledb.com -- посмотрите ее рекламный ролик. Кстати, это нереляционная база данных). Меня в базах данных привлекает не столько возможность быстрого ввода данных или даже быстрого редактирования данных, сколько возможность генерации отчета. Если мне из небольшого количества сложнопровязанной информации полимодели нужно сгенерировать много разных относительно простых групп описаний, то мне нужен генератор отчетов. Увы, генераторов отчета для Exel с Gellish не существует. Поэтому проще взять какую-нибудь из существующих баз данных с генератором отчетов и поработать с ней.

> Поэтому для меня ваш текст странен: вы пишете про какое-то странное подподподмножество баз данных. http://en.wikipedia.org/wiki/Document-oriented_database > Сейчас все онлайновые базы хвастаются, что их схемы можно менять на лету, и предлагают инкрементальное построение этих схем (например, та же dabbledb.com -- посмотрите ее рекламный ролик. Добавление/удаление атрибута один из случаев изменения схемы (единственный если сущности не связаны). Проблема возникает с потерей информации при удалении атрибута. Если сущностей много и между ними установлены отношения, возникает несколько ситуаций потерь информации при преобразовании схемы. Если мы не ограничены требованием сохранения целостности данных и информации при изменении схемы решения dabbledb.com, infodome.com, zoho creator вполне приемлемые. ИМХО в исходном посте речь шла об отказе от контроля целостности на уровне схемы и атомарности атрибутов сущности (минимум отказ от сравнения единичных значений, иначе чем текстовое сравнение), соответственно было предложено "решение" работающее в указанных ограничениях. > Кстати, это нереляционная база данных). реляционная, данные хранятся в 1NF, с нарушением условия дубликатов кортежей > Увы, генераторов отчета для Exel с Gellish не существует. Поэтому проще взять какую-нибудь из существующих баз данных с генератором отчетов и поработать с ней. Возможно ересь, но схема Gellish ->RDF -> генератор отчетов использующий SPARQL возможно решит проблему. Это при условии, что целостность таблиц Gellish в Excel контролируются (что возможно если верить создателю Gellish).

Ностальгия: я в 80-х работал в мединституте и сталкивался с MUMPS на СМ-4 :))) Понятно: "документ-ориентированная база данных" для этих разнородных систем термин не всегда употребляется, ибо я только вчера встречал множество имен из этого списка под совсем другими ярлыками. Вот и не понял сразу, о чем речь. Нет, меня тут не столько целостность данных при изменениях схемы интересует, сколько работа с нетабличными данными. Поэтому указанное направление вполне перспективно. Увы, Gellish->RDF еще нужно уметь запрограммировать (есть разворачивалка шаблонов в стиле ISO 15926 в триплеты, она работает в iRING, но для этого нужно ухитриться поставить iRING -- на сегодня для этого точно нужен хороший сисадмин, это проверяли наши коллеги). Затем нужно организовать к triple-store доступ из генератора отчетов, который использует SPARQL. Удовольствие опять-таки из крутопрограммистских (что-то я не слышал о WYSIWYG-инструментах, которые внутре имеют SPARQL. Наоборот, юзание этих инструментов требует повышенного образовательного ценза). Так что ровно от такого решения я ухожу. Итак: интересно, есть ли какая-то из этих документоориентированных баз данных с генератором отчетов, который легко программировать, а сама база данных не требует установки администратором? Повторюсь, чтобы было понятно, о чем я: выходной отчет мог бы выглядеть примерно так -- http://www.verdewek.com/openmetis/Download/OPENMetisWhitePaper.zip, он сделан "вручную" по очень похожей, но не стандартной схеме. Стандартная схема такой базы данных в ISO 24774 (у системных инженеров этот стандарт должен быть полностью, а вот фрагмент приведен и описан в http://ailev.livejournal.com/817706.html). По-хорошему, конечно, нужно бы использовать ISO15926 в стиле Gellish (в табличном формате отношений), но софта такого с генератором отчетов нет и пока не предвидится. Вот я и думаю, как автоматизироваться хотя бы на треть. А пока пишу подобный "репорт" для методологии моделеориентированной инженерии требований вообще без базы данных, вручную в Ворде. Но это опять-таки лучше формата серии постингов в ЖЖ, хотя и не гарантирует целостности ни данных, ни схемы :)

Посмотрел несколько вариантов. Если честно, более всего понравилось dabbledb.com, действительно быстро и удобно. А если писать по-русски, то можно даже не заморачиваться платным доступом :-) Меня единственно что смущает, как работать с картинками. В любом приличном отчете достаточно много графики, причем графики структурной, связанной с текстом. Т.е. если берем в рассмотрение сущности определенной группы, то они должны появиться как в тексте, так и на картинке. ИМХО, одна из самых "загадочных" задач (под которые я вообще не видел приличного инструмента пока), которую придется решать в рамках "методологии моделеориентированной инженерии требований". Было бы очень ценным, если бы Вы выложили все-таки то решение, которое найдете.

"Сущности, которые появляются в графике" -- это как раз и есть тот поиск универсального моделера, способного работать с графическими DSL. Увы, пока такого нет (а те, которые есть, не подходят).

К слову - в dabbledb.com не работают и более простые вещи. Пробовал сделать две пересекающиеся иерархии (одна является источником свойств для другой) - система начала глючить. Вот тебе и верь в простоту работы визуальных инструментов. :-(

Может тогда посмотреть в сторону DITA (http://www.philosoft.ru/dita-intro.zhtml). Для автоматизации сборки документов из выделенных выборкой по тегам кусков, решения отработаны. Потом можно будет перенести информацию в БД.

Нет, там генератор отчетов описан, только вообще без базы данных, только со схемой базы данных :) Уж проще документ руками весь сначала сделать, а потом перенести на схему+данные+формат_отчета и попробовать воспроизвести ручной формат...

В 24744 ВидыЕдиницРаботы - абстрактный класс (не порождает экземпляры), но имеет три неабстрактых субкласса. Может для каждого из них по таблице?

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

MS Access - приемлимо (ИМХО), с последующим экспортом в Excel/GoogleDocs.

Нужен экспорт (т.е. генерация отчетов) в .pdf (для красивой распечатки, рассматриваемой потом менеджерами).