Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Требуется выбрать базу данных /* Договоры, в отличие от бухгалтерских документов, трудно представить в виде таблицы, они, вообще говоря, являются трудно формализуемой информацией. В то же время, держать для каждого из тысячи клиентов отдельный файл с текстом договора, согласованным и скорректированным под него, не вполне удобно, а подписать со всеми одинаковый текст при условии наличия конкурентов - нереально. Для трудноформализуемой информации, часть из которой нужно хранить в виде текста и сопровождать многочисленными комментариями, последние годы используют СУБД на основе XML. То есть, или вся информация хранится в виде системы каталогов и XML документов, или часть информации, хранится в реляционной БД, а часть в XML документах. */ Это не мои слова как вы поняли уже а цитата... Такая же трабла и у меня - трудноформализуемые данные... Что посоветуете? Следовать примеру? или ... У меня есть ещё мысль использовать ООДБ. Кстати проект на С++ - вдруг это вам важно Поделитесь опытом плз. ИМХО Чем больше мнений тем оптимальней выбор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 14:58 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Действительно задачка не из тривиальных. Дело пахнет CRM-системой? Дать однозначный ответ сложно. ООБД - хороши, но геморроя с ними больше чем надо... XML - тоже штука в себе... Нужно смотреть на задачу: скажу по себе - для реализации одного из "ТРУДНОФОРМАЛИЗУЕМЫХ" проектов пришлось серьезно повозиться с выбором и в конце концов остановиться на ОRACLE+XML. Проект был связан с CRM - проектом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 15:16 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Смотря с какой целью будет эта неформализованная информация потом использоваться. На мой взгляд, если нужно просто организовать хранилище этой информации, то подойдёт любая промышленная СУБД. Хранить данные можно в LOB объектах, контекстный поиск тоже организовать можно. Например, в нашем проекте для хранилища документов используются объектны на основе типа ORDDoc оракла. Если необходимо как-то всё же вычленять общие атрибуты из набора неструктурированных информационных объектов - тогда нужно хранить такие объекты в виде XML, но в базе данных, естесственно :). Тоже, конечно, моё мнение. В нашем случае так же остановились на Oracle XMLDB. Так или иначе построить модель этой неструктурированной информации желательно, например, при помощи UML, может, после этого какое-нибудь решение придёт само собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 15:22 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Я вот что-то не вижу связи между Договоры, в отличие от бухгалтерских документов, трудно представить в виде таблицы, они, вообще говоря, являются трудно формализуемой информацией и XML - что, XML даст возможность не хранить весь договор???? Помоему, любая СУБД + нормально спроектированная система подойдет. Не хотите хранить весь документ - хорошо, храните только измененные части. Только вот что будете делать, если базовая форма изменится? И какие проблемы с хранением хоть 1000 договоров для 10000 клиентов? Лишний гигабайт? Дык винты сейчас дешевые. Так что по мне - проблема надуманная. Изобретение нового велисапеда -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 16:01 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Делаешь так: Берешь договор в левую руку, текстовыделеить (маркер ) в правую. Идешь по договору и выделяешь те места, которые меняются от договора к договору. Выделенную информацию разбиваешь на сущности/связи (проектируешь таблицы) а оставшийся тест - будет шаблоном, коих может быть много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 16:09 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Да, и еще, договор - довольно иерархическая структура. Шаблон - те же заголовок, параграфы, пункты, подпункты... - XML структура А стороны договора - суммы - реквизиты - сущности.... их в базу) PS. Легко давать советы, но я правда таким пока еще не занимался, но предстоит) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 16:12 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Ну что уж тогда только XML - надо еще и на Java писать, иначе ничего не получится авторИдешь по договору и выделяешь те места, которые меняются от договора к договору. Выделенную информацию разбиваешь на сущности/связи (проектируешь таблицы) а оставшийся тест - будет шаблоном, коих может быть много Тяжко будет, когда шаблон изменится. Хотя если контролировать версии... Но смысл?! Договор составили - и все. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 16:44 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Самый классный вариант чтоб долго не мучицца - сканировать договор и хранить JPg прям в базе. - Гарантия неизменности) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 17:56 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
--а оставшийся тест - будет шаблоном, коих может быть много в данном случае это header and footer для репорта, которые в современных репорт-компонентах обычно как xml-документа (RDF формат), данные из базы просто вставляются компонентом. Тогда пользователь может выбирать любой тип дизайна и любые данные для него ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 21:02 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
кстати посмотри как FineRedaer хранит формат документа в XML ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2004, 21:03 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
авторСамый классный вариант чтоб долго не мучицца - сканировать договор и хранить JPg прям в базе. - Гарантия неизменности) Еще класснее :) хранить сам документ ЗЫ Я все-же не пойму, зачем тут XML то? Тошнить меня от него -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2004, 11:52 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Дело в том, что само использование XML мне не улыбается - это ж дополнительный парсинг - соответственно потери времени... Я уверен есть способы и без него всё правильно организовать если я не прав - поправте плз Не хочется выдумывать велосипед когда времени не многа... ИМХО Чем больше мнений тем оптимальней выбор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 13:42 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Если не XML, то как хранить договор? Можно в виде обычного текста, можно просто загрузить в виде png или gif файла (не jpg). Но если придется обрабатывать документы, то что может быть лучше XML? Denis V. ValchukДело в том, что само использование XML мне не улыбается - это ж дополнительный парсинг - соответственно потери времени... А как обрабатывать, так XML может окажться самым быстрым ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 15:06 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
авторНо если придется обрабатывать документы, то что может быть лучше XML? Да хоть что. А чем XML лучше хоть чего? SQL server есть - чего еще надо? В таблицах разместить - нет проблем. 2 Denis V. Valchuk Дык чего собственно нужно? Тут высказали пару версий без XML. Храни или весь документ, или шаблон. При открытии в шаблон подставляй нужные места - и все. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 16:56 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Подскажите терь книгу чтоли... хорошую :) а то я базы ещё не проэктировал... А тут ещё и пахнет редактором этих документов... :( ИМХО Чем больше мнений тем оптимальней выбор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 18:05 |
|
||
|
Помогите сделать правильный выбор
|
|||
|---|---|---|---|
|
#18+
Что посоветуете? Следовать примеру? или ... Сначала или. Сам договор кто-то составляет? Правильно, составляет. Ворд ему в руки. В документе составитель выделяет фрагмены, которые должны заполняться данными берущимися из базы. Отмечает это дело букмарками. Дает букмаркам имена. Эти имена считай именами свойств документа. И подбираешь хранение данных таким, чтобы имена можно было указывать косвенно, скажем на sql (прошу прощения, давненько его в руки не брал, могу ошибиться): -- храним сами шаблоны create table dyndoctemplate ( id integer, -- номер шаблона docname varchar, -- как показать его в списе, на всякий случай template binary -- тут сам вордовый шаблон ) -- храним имена букмарков create table dyndoc ( templid integer, -- для какого шаблона attrname varchar -- как называется ) -- храним значения букмарков, это собсно и есть данные документов create table dyndocattr ( docid integer, -- экземпляр документа templid integer, -- для какого шаблона attrname varchar, -- имя букмарка attrvalue varchar -- значение букмарка ) В третьей таблице имитируется таблица с "виртуальными" строками (строка - это все с одинаковым docid) и переменным числом колонок (имя колонки это attrname, значение attrvalue). А с помощью OLE Automation залупить ворду блоб и пройтись по букмаркам - дело копеечное. С табличной частью мысль нужно продолжить. Идея в принципе понятна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 19:23 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32436653&tid=1546573]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
170ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 535ms |

| 0 / 0 |
