|
Как правильно спроектировать финансовый учёт разных сущностный
|
|||
---|---|---|---|
#18+
Добрый день. На данный момент спроектировано так, что на каждую сущность имеется отдельная структура БД. Например за продажу услуг отвечает один набор таблиц финансового учёта, за продажу абонементов или подарочных сертификатов другой набор таблиц и т.п. Есть и плюсы и минусы такого подхода... но вопрос сейчас не в этом. Существуют ли подходы, при которых все финансовые данные будут храниться в одном месте (в одной структуре БД)... что-то типа "document - item"? Есть ли ресурсы, где можно посмотреть примеры такого подхода? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2020, 15:50 |
|
Как правильно спроектировать финансовый учёт разных сущностный
|
|||
---|---|---|---|
#18+
Игорь_UUSЕсть ли ресурсы, где можно посмотреть примеры такого подхода? Да. Любой учебник проектирования БД по Entity-Relation методу. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2020, 17:06 |
|
Как правильно спроектировать финансовый учёт разных сущностный
|
|||
---|---|---|---|
#18+
Игорь_UUS На данный момент спроектировано так, что на каждую сущность имеется отдельная структура БД. Например за продажу услуг отвечает один набор таблиц финансового учёта, за продажу абонементов или подарочных сертификатов другой набор таблиц и т.п. Я так понимаю всё рабочее уже? Иначе бы не возникло вопроса... По идее (если в кратце), услуги, абонементы, сертификаты и прочее можно объединить в одну сущность с признаком что это такое (например через классификатор: 1- услуга, 2 - сертификат, 3- абонемент и т.д.) а потом включать нужные алгоритмы обработки в соответствии с признаком из числа существующих. Естественно некоторые ветви в общей структуре будут не задействованы для отдельных типов, например для услуг не будет прихода как для товара (только корректировка самих услуг: добавление, удаление, корректировка цены). Насколько это оправдано судить вам, будет одна структура и добавление нового типа повлечет добавление нового типа в классификатор и новых алгоритмов его обработки (если они отличаются от уже существующих), в принципе задача вполне решаемая, будет просто больше нагрузки на интерфейс, имхо почти везде и у всех так и реализовано (за исключением 1С - там каждый чих это отдельный документ, но и у них это всё таки в одной структуре БД).... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 02:01 |
|
Как правильно спроектировать финансовый учёт разных сущностный
|
|||
---|---|---|---|
#18+
Игорь_UUS, Гуглить supertype-subtype relationship. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 03:07 |
|
Как правильно спроектировать финансовый учёт разных сущностный
|
|||
---|---|---|---|
#18+
Игорь_UUS Добрый день. На данный момент спроектировано так, что на каждую сущность имеется отдельная структура БД. Например за продажу услуг отвечает один набор таблиц финансового учёта, за продажу абонементов или подарочных сертификатов другой набор таблиц и т.п. Есть и плюсы и минусы такого подхода... но вопрос сейчас не в этом. Существуют ли подходы, при которых все финансовые данные будут храниться в одном месте (в одной структуре БД)... что-то типа "document - item"? Есть ли ресурсы, где можно посмотреть примеры такого подхода? Посмотреть, как сделано в Compiere / iDempiere. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2020, 11:45 |
|
|
start [/forum/topic.php?fid=32&fpage=4&tid=1539874]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 250ms |
total: | 402ms |
0 / 0 |