Справочники как сервисы
От: thanks  
Дата: 28.08.09 18:47
Оценка:
Здравствуйте.
Занимаюсь проектом с несколькими модулями, например, "кафедра" и "кадры". Всем модулям нужны общие справочники, например "адреса", которые в свою очередь тянут "страны", "регионы", "города", "улицы" и т.п.

Мне бы хотелось что бы все модули использовали единый подход к справочникам (для примера, адресам), т.е. сущность, использующая адрес, хранила бы какой-нибудь идентификатор адреса и когда нужно обращалась бы к сервису который вернёт уже саму сущность адреса, которая хранит идентификаторы страны, городов и т.д.

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

Как вообще в корпоративных системах организуется работа со справочниками? Может где-то упоминается?
Re: Справочники как сервисы
От: Sheridan Россия  
Дата: 29.08.09 11:23
Оценка: +1
Приветствую, thanks, вы писали:

t> Мне бы хотелось что бы все модули использовали единый подход к справочникам (для примера, адресам), т.е. сущность, использующая адрес, хранила бы какой-нибудь идентификатор адреса и когда нужно обращалась бы к сервису который вернёт уже саму сущность адреса, которая хранит идентификаторы страны, городов и т.д.

Правильная мысль.

t> Вопрос в том, насколько это адекватно. Я не хочу что бы каждый модуль хранил у себя справочную информацию (у модулей могут быть разные БД) и ничего кроме как выделения справочников в сервисы придумать не получается.

А чем это плохо? имхо это наоборот очень правильная мысль — выделить справочники в сервисы.

t> Как вообще в корпоративных системах организуется работа со справочниками? Может где-то упоминается?

Да в основном никак. Весь софт таскает все с собой. По крайней мере я еще не встречал какихто общих сервисов.

В качестве справочника городов-улиц, а точнее БД этого дела — ищи КЛАДР. Эта штука хотя и распространяется в dbf, но никто не мешает сделать импорт в свою бд.
avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2
Matrix has you...
Re: Справочники как сервисы
От: paucity  
Дата: 29.08.09 11:47
Оценка:
Здравствуйте, thanks, Вы писали:

T>Как вообще в корпоративных системах организуется работа со справочниками? Может где-то упоминается?


Master Data Management?
Re: Справочники как сервисы
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.08.09 07:38
Оценка: 2 (1)
Здравствуйте, thanks, Вы писали:


T>Здравствуйте.

T>Занимаюсь проектом с несколькими модулями, например, "кафедра" и "кадры". Всем модулям нужны общие справочники, например "адреса", которые в свою очередь тянут "страны", "регионы", "города", "улицы" и т.п.

T>Мне бы хотелось что бы все модули использовали единый подход к справочникам (для примера, адресам), т.е. сущность, использующая адрес, хранила бы какой-нибудь идентификатор адреса и когда нужно обращалась бы к сервису который вернёт уже саму сущность адреса, которая хранит идентификаторы страны, городов и т.д.


T>Вопрос в том, насколько это адекватно. Я не хочу что бы каждый модуль хранил у себя справочную информацию (у модулей могут быть разные БД) и ничего кроме как выделения справочников в сервисы придумать не получается.


T>Как вообще в корпоративных системах организуется работа со справочниками? Может где-то упоминается?


Есть набор общероссийских классификаторов по разным отраслям. Большинство из них поддерживается государственными структурами.
Re: Справочники как сервисы
От: GlebZ Россия  
Дата: 30.08.09 09:43
Оценка:
Здравствуйте, thanks, Вы писали:

Мысль и хорошая, и нехорошая в зависимости от обстоятельств.
Ну например, тебе нужно получить все обращения гражданина Попкина в отдел нумер 47. Ежели справочник обращений, справочник граждан, и справочник отделов разные, то это более менее бесплатно с помощью SQL запроса не получится.
К тому же нужно учитывать многие вещи. Например, для зарплат достаточно важна официальная иерархия подчиненности. Тот работает в отделе 1 на должности ассенизатора. Этот работает в отделе 2 на должности старшего уборщика. В то же время, например при документообороте, важны проектные группы. В которой старший уборщик и ассенизатор работают в одной проектной группе по озеленению клумбы.
Вобщем, для каждой прикладной системы должен быть выбран свой подход.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.