Система электронного учета документов

@tkrainyk · Регистрация: 09.12.2016

Author24 — интернет-сервис помощи студентам

Прошу совета у специалистов.

У нас на предприятии хотят ввести систему электронного учета документов.

Можно было бы эту задачу выполнить на Access ?

Сама структура базы более или менее понятна (по ходу работы уточнится).

Но что делать с объемом базы. Часть документов планируется сканировать. Так как оборот документов в день около 50, примерно за год мы перейдем границу в 2 Гб.

Может кто-то выполнял подобную задачу, прошу посоветовать какой выход из положения.

Или сказать руководству, что Access для таких задач неприменим, и надо покупать систему электронного документооборота ?

mobile · 27.07.2017, 15:29

Ничего особенного 2 Гб. И покупать дорогущую систему документооборота не нужно. Есть 2 популярных выхода:
- в БД храним не сами доки, а только пути к ним. В год это будет не больше нескольких мегабайт. При необходимости обратиться к документу, считываем его по адресу с диска. Это доли секунды.
- интерфейс оставить в Access, а сами сканы хранить на промышленном сервере - MS SQL Server, MySql и подобных. MySql и PostgreSql бесплатные.

@tkrainyk · 27.07.2017, 18:19 **[ТС]**

Спасибо, mobile!

Стараюсь обдумать ваш ответ.

Извиняюсь за свои не совсем умные вопросы, но опыт работы с Access около 1 года.

1. В базе хранится путь к файлу. Открываем его по указанному пути с Access. С этим все понятно.
Но теперь попробуем смоделировать ситуацию работы пользователя. Он сканирует файл на компьютер. А куда потом перебросить этот файл, и как внести путь в базу он не знает .........

2. В Access 2010 есть очень удобное поле "вложение". Будет ли оно так же работать например с ms sql server.

mobile · 27.07.2017, 19:01

Если у Вас Access 2007 и ниже (2003, 2002), то сканировать можно напрямую из акса, пользуясь библиотекой Microsoft Office Document Imaging 11.0 (или 12.0 для 2007) Viewer Control. В этом случае все проблемы именования исчезают. Ничего особенного в коде нет, в сети множество примеров.
К сожалению, начиная с А2010, библиотека исключена из офиса и предлагается пользоваться аналогом через SharePoint.

Поле Вложение многозаписное, аналогов в скл-сервере нет.

Чтобы моделировать оператора, надо создать регулярную систему имен и сканировать в определенную папку. Затем из акса считать имена файлов и пользуясь системой имен, расшифровать что к чему и записать адреса файлов в соответствующие записи таблицы.

@Eugene-LS · 27.07.2017, 21:06

Сообщение от mobile

и записать адреса файлов в соответствующие записи таблицы

Позволю себе подправить чутка - лучше хранить только имена файлов, т.к. их адрес может меняться со временем.
А полный путь к файлу - получаем по настройкам на клиентской машине.

@alvk · 28.07.2017, 05:58

Сообщение от Eugene-LS

лучше хранить только имена файлов, т.к. их адрес может меняться со временем.

Лучше взять всё под свой контроль.
1. Файлы заносим в программу своей обработкой. Пользователь выбирает файл (Application.FileDialog)
получаем тут же его путь, где он лежит.
2. Переименовываем как нам надо, я например вставляю в его имя код.
3. Копируем в специальную папку на сервере.
4. Заносим в базу путь к этому файлу. Если расширения разные, то и расширение.
5. Для просмотра строим путь к файлу + имя + . + расширение, открываем уже хоть shell(), хоть чем угодно.

p.s. это сокращённый вариант, у меня длиннее, специфика.

@VinniPuh · 28.07.2017, 07:40

Сообщение от alvk

...это сокращённый вариант, у меня длиннее, специфика...

Эхх, хоть бы одним глазком глянуть.
Тоже давно такое сотворить хочу для интереса и общего образования, даже кое какие планы в голове неоднократно набрасывал, но как то всё не решаюсь, т. к. кажется сложноватым для меня, всего такого несовершенного.

@VinniPuh · 28.07.2017, 08:24

tkrainyk, Кстати, для интереса полазил по другим форумам и узрил, что наш - Панург сёдня выложил примерчик, с похожей на вашу задачку, типа как хранить отдельно от БД файлики и открывать их по нужде.

@tkrainyk · 28.07.2017, 15:49 **[ТС]**

Спасибо всем за советы.

Очень понравился пример Панурга.

Но все это мне как-то сложновато.

Поэтому я решил сделать так (наверно немного смешно для профессионалов):

Делаем базу Документы. В работе используем только встроенные средства Access, в том числе и поле вложение. А далее где-то марте копируем файл как Архив2017. С архива Удаляем все документы после 1 января, с базы Документы - до 1 января (таблицы со справочниками оставляем). И продолжаем работать еще один год.

shanemac51 · 28.07.2017, 16:07

Сообщение от tkrainyk

Так как оборот документов в день около 50

сделайте пример базы --введите 50 сканов
затем посмотрите --какой будет размер базы
попробуйте создать парочку форм отчетов----только потом решайте, будете ли вы развивать этот путь
пусть попробует исполнитель сделать свою типичную дневную работу

===================
работать с базой в 2-5мб легко
при 20-50 ---уже явная приторможенность
если более 250-500 уже явные тормоза, даже в локальном исполнении

а ведь вы хотите работать видимо по сети

@alvk · 28.07.2017, 20:55

Сообщение от tkrainyk

в том числе и поле вложение.

вот оно то и приведёт вас к яме в будущем.

@tkrainyk · 29.07.2017, 13:58 **[ТС]**

Спасибо, shanemac51 и alvk, что своевременно подсказали.

Я то по своей наивности полагал, что если написано 2 Гб, то база будет работать при таком размере в сети.

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

Между прочим, пример Панурга уже содержит полное решение задачи.

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

Думаю, что справлюсь.

Еще раз всем спасибо.

@tkrainyk 775 / 256 / 43 Регистрация: 09.12.2016 Сообщений: 855
		1
	Система электронного учета документов 27.07.2017, 15:10. Показов 9543. Ответов 11 Метки нет (Все метки) Прошу совета у специалистов. У нас на предприятии хотят ввести систему электронного учета документов. Можно было бы эту задачу выполнить на Access ? Сама структура базы более или менее понятна (по ходу работы уточнится). Но что делать с объемом базы. Часть документов планируется сканировать. Так как оборот документов в день около 50, примерно за год мы перейдем границу в 2 Гб. Может кто-то выполнял подобную задачу, прошу посоветовать какой выход из положения. Или сказать руководству, что Access для таких задач неприменим, и надо покупать систему электронного документооборота ? 0

mobile 26815 / 14494 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	27.07.2017, 15:29	2
	Ничего особенного 2 Гб. И покупать дорогущую систему документооборота не нужно. Есть 2 популярных выхода: - в БД храним не сами доки, а только пути к ним. В год это будет не больше нескольких мегабайт. При необходимости обратиться к документу, считываем его по адресу с диска. Это доли секунды. - интерфейс оставить в Access, а сами сканы хранить на промышленном сервере - MS SQL Server, MySql и подобных. MySql и PostgreSql бесплатные. 1

@tkrainyk 775 / 256 / 43 Регистрация: 09.12.2016 Сообщений: 855
	27.07.2017, 18:19 [ТС]	3
	Спасибо, mobile! Стараюсь обдумать ваш ответ. Извиняюсь за свои не совсем умные вопросы, но опыт работы с Access около 1 года. 1. В базе хранится путь к файлу. Открываем его по указанному пути с Access. С этим все понятно. Но теперь попробуем смоделировать ситуацию работы пользователя. Он сканирует файл на компьютер. А куда потом перебросить этот файл, и как внести путь в базу он не знает ......... 2. В Access 2010 есть очень удобное поле "вложение". Будет ли оно так же работать например с ms sql server. 1

mobile 26815 / 14494 / 3192 Регистрация: 28.04.2012 Сообщений: 15,782
	27.07.2017, 19:01	4
	Если у Вас Access 2007 и ниже (2003, 2002), то сканировать можно напрямую из акса, пользуясь библиотекой Microsoft Office Document Imaging 11.0 (или 12.0 для 2007) Viewer Control. В этом случае все проблемы именования исчезают. Ничего особенного в коде нет, в сети множество примеров. К сожалению, начиная с А2010, библиотека исключена из офиса и предлагается пользоваться аналогом через SharePoint. Поле Вложение многозаписное, аналогов в скл-сервере нет. Чтобы моделировать оператора, надо создать регулярную систему имен и сканировать в определенную папку. Затем из акса считать имена файлов и пользуясь системой имен, расшифровать что к чему и записать адреса файлов в соответствующие записи таблицы. 1

@Eugene-LS 10741 / 5582 / 1409 Регистрация: 05.10.2016 Сообщений: 15,787
	27.07.2017, 21:06	5
	Сообщение от mobile и записать адреса файлов в соответствующие записи таблицы Позволю себе подправить чутка - лучше хранить только имена файлов, т.к. их адрес может меняться со временем. А полный путь к файлу - получаем по настройкам на клиентской машине. 1

@alvk 7439 / 4574 / 300 Регистрация: 12.08.2011 Сообщений: 14,228
	28.07.2017, 05:58	6
	Сообщение от Eugene-LS лучше хранить только имена файлов, т.к. их адрес может меняться со временем. Лучше взять всё под свой контроль. 1. Файлы заносим в программу своей обработкой. Пользователь выбирает файл (Application.FileDialog) получаем тут же его путь, где он лежит. 2. Переименовываем как нам надо, я например вставляю в его имя код. 3. Копируем в специальную папку на сервере. 4. Заносим в базу путь к этому файлу. Если расширения разные, то и расширение. 5. Для просмотра строим путь к файлу + имя + . + расширение, открываем уже хоть shell(), хоть чем угодно. p.s. это сокращённый вариант, у меня длиннее, специфика. 2

@VinniPuh 9108 / 6037 / 590 Регистрация: 27.03.2013 Сообщений: 19,810
	28.07.2017, 07:40	7
	Сообщение от alvk ...это сокращённый вариант, у меня длиннее, специфика... Эхх, хоть бы одним глазком глянуть. Тоже давно такое сотворить хочу для интереса и общего образования, даже кое какие планы в голове неоднократно набрасывал, но как то всё не решаюсь, т. к. кажется сложноватым для меня, всего такого несовершенного. 1

@tkrainyk 775 / 256 / 43 Регистрация: 09.12.2016 Сообщений: 855
	28.07.2017, 15:49 [ТС]	9
	Спасибо всем за советы. Очень понравился пример Панурга. Но все это мне как-то сложновато. Поэтому я решил сделать так (наверно немного смешно для профессионалов): Делаем базу Документы. В работе используем только встроенные средства Access, в том числе и поле вложение. А далее где-то марте копируем файл как Архив2017. С архива Удаляем все документы после 1 января, с базы Документы - до 1 января (таблицы со справочниками оставляем). И продолжаем работать еще один год. 0

shanemac51 Модератор 12082 / 4942 / 791 Регистрация: 07.08.2010 Сообщений: 14,509 Записей в блоге: 4
	28.07.2017, 16:07	10
	Сообщение от tkrainyk Так как оборот документов в день около 50 сделайте пример базы --введите 50 сканов затем посмотрите --какой будет размер базы попробуйте создать парочку форм отчетов----только потом решайте, будете ли вы развивать этот путь пусть попробует исполнитель сделать свою типичную дневную работу =================== работать с базой в 2-5мб легко при 20-50 ---уже явная приторможенность если более 250-500 уже явные тормоза, даже в локальном исполнении а ведь вы хотите работать видимо по сети 2

@alvk 7439 / 4574 / 300 Регистрация: 12.08.2011 Сообщений: 14,228
	28.07.2017, 20:55	11
	Сообщение от tkrainyk в том числе и поле вложение. вот оно то и приведёт вас к яме в будущем. 2

	29.07.2017, 13:58

@tkrainyk 775 / 256 / 43 Регистрация: 09.12.2016 Сообщений: 855
	29.07.2017, 13:58 [ТС]	12
	Спасибо, shanemac51 и alvk, что своевременно подсказали. Я то по своей наивности полагал, что если написано 2 Гб, то база будет работать при таком размере в сети. Тогда возвращаемся к первому варианту: храним в базе только пути к документам. Между прочим, пример Панурга уже содержит полное решение задачи. Я думаю там что-то модифицировать, но это значительно легче, чем писать самому код с самого начала. Думаю, что справлюсь. Еще раз всем спасибо. 0

Система электронного учета документов

Решение