powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Наращивание функционала и смена версий: проблемы и методы
11 сообщений из 11, страница 1 из 1
Наращивание функционала и смена версий: проблемы и методы
    #32938126
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Время идет, люди работают. Как разработчики систем, так и их пользователи, при этом не зависимо друг от друга.

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

С другой стороны, хороший инструментарий ERP-систем позволяет пользователям на местах выполнять свои доработки. Пользователи могут изменить структуру базы данных, изменить работу каких либо процедур, добавить свои процедуры, документы, операции. Как в таком случае передать пользователю доработки поставщика системы, не задев и не испортив работу пользователя?

Первую проблему я решаю путем разделения системы на модули: одна задача – это один модуль со своей отдельной базой данных. Вроде бы хорошо получилось, но хотелось бы узнать и другие варианты. На счет второй проблемы - вообще не знаю, как к ней подойти. Поделитесь, кто может, решениями или идеями. Думаю, что это представляет интерес не только для меня.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32938401
brainwashed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У нас пользователи (разработчики со стороны пользователей) действительно вносят изменения только в своей схеме. Т.е. не трогают ядра системы. Уживаемся с ними неплохо:)
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32938747
michael_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVP
Первую проблему я решаю путем разделения системы на модули: одна задача – это один модуль со своей отдельной базой данных.

А общие справочники (сотрудники, контрагенты, товары и т. д.) в какой базе?
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32938823
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
michael_А общие справочники (сотрудники, контрагенты, товары и т. д.) в какой базе?Сотрудники - это модуль "Зарплата", в нем все, что связано с сотрудниками. Контрагенты - модуль "Партнеры", товары - модуль "Материалы", и т.д. Мо всех модулях структура базы данных в системной части одинакова. Отличается только параметрами в таблице лицевых счетов, таблице справочников и таблице операций. Одна база данных оригинальная - база администратора. Она используется для управления комплектацией системы, управлющим меню, защитой доступа.

Если требуется межмодульная связь, например в модуле "Материалы" доступ к контрагентам, то в этом модуле создается справочник, но вместо наполнения его данными указывается ссылка на справочник с другого модуля. Если модуль используется автономно, то данные в справочник вводятся в нем.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32939284
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVPвместо наполнения его данными указывается ссылка на справочник с другого модуля
Как, если не секрет ? (Речь идёт именно про БАС). :)
У Вас в системе несколько TADOConnection ?
И как в таком случае строится отчётность ?
Как быть, когда приобретается новый модуль, в котором тоже есть точно такой-же справочник ? Переносить данные и перенаправлять ссылку ?

По теме: Невозможно делать критические доработки (удалять поля, переносить логику/данные из одной таблицы в другую) и быть уверенным, что пользователи не пострадают. Сложно даже в случае наличия примочки для миграции из старой системы в новую.
Это краеугольный камень любой системы, и одна из причин наличия огромного числа устаревших систем.
PVPПользователи могут изменить структуру базы данных
Логическую - да, физическую - нет. Могут добавить абсолютно новую, но не меняя старую. В любой серьёзной системе всё очень взаимосвязано. Стоит тронуть в одном месте и где потом всплывёт г...о , никто не знает.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32939582
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LSV PVPвместо наполнения его данными указывается ссылка на справочник с другого модуляКак, если не секрет? (Речь идёт именно про БАС). :) Все справочники находятся в одной таблице. Имя таблицы во всех базах одинаковое. При настройке справочника указывается его код, название и набор параметров. Если это ссылка, то указывается модуль и код справочника. В текущем модуле назначается только защита доступа.

LSVУ Вас в системе несколько TADOConnection ?
И как в таком случае строится отчётность ? TADOConnection столько, сколько модулей. На отчетность это не влияет, так как вся бизнес логика построена на хранимых процедурах, в т.ч. и документатор, а из них имеется свободный доступ ко всем базам, подключенным к серверу.

LSVКак быть, когда приобретается новый модуль, в котором тоже есть точно такой-же справочник? Переносить данные и перенаправлять ссылку ? В зависимости от ситуации, можно и так и так. Даже если в справочнике есть данные, то при наличии ссылки на другой модуль они игнорируются.

LSVПо теме: Невозможно делать критические доработки (удалять поля, переносить логику/данные из одной таблицы в другую) и быть уверенным, что пользователи не пострадают. Сложно даже в случае наличия примочки для миграции из старой системы в новую.
Это краеугольный камень любой системы, и одна из причин наличия огромного числа устаревших систем. Оптимизм не позволяет поверить в невозможность. Должны же быть хоть какие то частные решения.

LSV PVPПользователи могут изменить структуру базы данныхЛогическую - да, физическую - нет. Могут добавить абсолютно новую, но не меняя старую. В любой серьёзной системе всё очень взаимосвязано. Стоит тронуть в одном месте и где потом всплывёт г...о , никто не знает.Я позволяю менять структуру основных таблиц на физическом уровне из интерфейсной части. Правда не всем пользователям, а только администратору (программисту). И не все поля, а только локальные параметры операций, документов, справочников. Эти поля не затрагивают индексов, связей между таблицами. Такой подход приводит к некоторой избыточности базы данных, но зато очень упрощает написание или корректировку процедур бизнес логики.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32940216
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
brainwashedУ нас пользователи (разработчики со стороны пользователей) действительно вносят изменения только в своей схеме. Т.е. не трогают ядра системы. Уживаемся с ними неплохо:)Если можно, расскажите о том, что относится к ядру системы.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32940294
brainwashed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.е. то, что разрабатываем мы. Они же работают в рамках своего блока, используя всю информацию, которая ведется в системе. Т.к. структуры практически не меняются, вероятность того, что у них что-нибудь попухнет из-за наших изменений, минимальна.
Отчеты, насколько я знаю, ваяют всякие, учет чего-то там сделали.
Плюс, т.к. код открыт, надо устраивать переодически контроль за тем, чтобы изменения в нашу часть не вносили.
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32940462
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To brainwashed
Не сочтите за назойливость, но все же…

brainwashedТ.е. то, что разрабатываем мы. Они же работают в рамках своего блока, используя всю информацию, которая ведется в системе. Каким образом разделяются эти блоки и что входит в ваш блок и блок пользователя?

brainwashedТ.к. структуры практически не меняются Что значит практически?

brainwashedПлюс, т.к. код открыт, надо устраивать переодически контроль за тем, чтобы изменения в нашу часть не вносили.Если внесли, то вы все таки подставляете свой код?
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32940677
brainwashed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кадры
Финансы
Склады
Закупки/продажи
Производство
Зарплата
Бухгалтерия
Бюджетирование...
:)
Это все находится в наших схемах (Oracle)
У них же есть своя схема в которой работают только они. Т.е. могут создавать там таблицы, пакеты, все, что душе угодно. Наша часть - только на просмотр.
В клиентской части у них есть возможность подключать свои формы+отчеты.

"Практически" - имелось ввиду то, что структуры основных справочников, таблиц и т.п. не меняются. Наращивается все обычно "сверху":)

Изменение нашей части - вплоть до отказа в техподдержке.

А чего это я один болтаю?:) Как у остальных дела обстоят?:)
...
Рейтинг: 0 / 0
Наращивание функционала и смена версий: проблемы и методы
    #32941500
Станислав C.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVPВремя идет, люди работают. Как разработчики систем, так и их пользователи, при этом не зависимо друг от друга.

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

С другой стороны, хороший инструментарий ERP-систем позволяет пользователям на местах выполнять свои доработки. Пользователи могут изменить структуру базы данных, изменить работу каких либо процедур, добавить свои процедуры, документы, операции. Как в таком случае передать пользователю доработки поставщика системы, не задев и не испортив работу пользователя?

Первую проблему я решаю путем разделения системы на модули: одна задача – это один модуль со своей отдельной базой данных. Вроде бы хорошо получилось, но хотелось бы узнать и другие варианты. На счет второй проблемы - вообще не знаю, как к ней подойти. Поделитесь, кто может, решениями или идеями. Думаю, что это представляет интерес не только для меня.
Это очень большая и сложная проблема. И, к сожалению, решаемая лишь частично...
Есть два решения (которые использовались в разное время в организации, где я еще не так давно работал):
1. отказаться от полной установки обновлений, ставить выборочно и только критически важные (например, изменение НДС, налогового учета и т.д.);

либо

2. согласовывать с разработчиками/техподдержкой все проводимые в базе данных изменения. (Естественно, что разработчик должен хранить у себя последнюю согласованную конфигурацию клиента).

Первый вариант предполагает хорошее знание структуры системы, так как необходимо будет "резать по живому".

Второй вариант предполагает, что у разработчиков/техподдержки мало клиентов и разработчики/техподдержка с клиентами находятся в хороших отношениях, так как предполагается передавать разработчикам "ноу-хау" клиентов в виде структуры данных и процедур для поддержания работоспособности "согласованной версии" и делить ответственность за изменяемые модули...

Есть, правда, еще третий вариант: все изменения делать своими силами, независимо от разработки новых версий. Но это остается для крупных организаций, которые могут себе позволить держать штат высококвалифицированных программистов...

А вообще-то, это все далеко неоднозначно...
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Наращивание функционала и смена версий: проблемы и методы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]