ЭЭЭЭЙЙЙЙ линуксоиды дмитрова вы живы ААА-УУУУ

[PS]

Смотреть в сторону MongoDB

у меня именно SQLite, как бы стандарт в этой операционке)))

Извиняюсь, но рекомендую почитать о разнице между SQL-базами данных (к ним относится SQLite) и noSQL СУБД (к ним относится MongoDB)

[qwerty12345]

Смотреть в сторону MongoDB

у меня именно SQLite, как бы стандарт в этой операционке)))

Извиняюсь, но рекомендую почитать о разнице между SQL-базами данных (к ним относится SQLite) и noSQL СУБД (к ним относится MongoDB)

да понял, что последняя не работает с SQL запросами и даже не реляционная СУБД.
Но, повторюсь, что у меня приложение работает только с SQLite - обычная реляционная СУБД.

[qwerty12345]

PS
Да вроде я всегда говорил о бизнес процессах))) и о фирмах, которые занимаются конкретно делами, требующими оформления документации малоквалифицированными пользователями, а не линуксоидами с 20-и летним стажем)))

Потом опять использовать преобразователь в др. сторону. Сказать куда пойдёт оформляж документа после такого преобразования?

Фигня, преобразователь использовать только для показа дельты. Хранить все варианты, откатываться к предыдущему. Многовато конечно по объему, но пофиг.

[qwerty12345]

Что то у меня впечатление, что идут два параллельных монолога))) постепенно переходящих в меряния письками, разрешите откланяться)))

[PS]

Но, повторюсь, что у меня приложение работает только с SQLite - обычная реляционная СУБД.

Проблема в выборе инструмента не под задачу.
Конечно существую различные конверторы SQL-запросов в MongoDB, но это "костыль" со всеми вытекающими (реализация неполного SQL-языка, наличие "прослойки" и тп)

[PS]

Да вроде я всегда говорил о бизнес процессах))) и о фирмах, которые занимаются конкретно делами, требующими оформления документации малоквалифицированными пользователями, а не линуксоидами с 20-и летним стажем)))

Извини, но вот это твои слова

я вообще-то видел документацию ряда международных фирм, видел программное обеспечение, обеспечивающее бизнес процессы

Для данной постановки вопроса приведены форматы, решающие вопросы документооборота. В зависимости от уровня подготовки, от уровня требуемой автоматизации бизнес-процессов и тп выбирается тот или иной формат. Это вопрос к архитектору процессов.

Потом опять использовать преобразователь в др. сторону. Сказать куда пойдёт оформляж документа после такого преобразования?

Фигня, преобразователь использовать только для показа дельты. Хранить все варианты, откатываться к предыдущему. Многовато конечно по объему, но пофиг.

Ну показали дельту. Посмотрел я на неё. Что дальше делать? Мне не нужен откат ко всему документу. Мне нужно влить только вот это конкретное изменение в свою ветку. Причём не из последнего, а из версии 1.5, к-рая была три мажорных версии назад.
К сожалению это родовая травма коллаборации на основе версионности.

[qwerty12345]

Опять кажется монологи)))
Хранить какждое изменение, как это ни прискорбно, причем не на основе дельт, а именно весь документ. Ну некрасиво, ун и пофиг. Конкретное изменение переносить ручками))) версионность будет.
немного по колхозному, но для небольших проектов покатит.

[PS]

Хранить какждое изменение, как это ни прискорбно, причем не на основе дельт, а именно весь документ. Ну некрасиво, ун и пофиг. Конкретное изменение переносить ручками)))

Именно про это я и гооворил в одном из первых сообщений моего участия в данном треде: "документы Word рассматриваются системами контроля версий blob-ами". Соотв-но "ад версий"

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

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