здравствуйте,
есть скажем таблица СЧЕТА ( ID,ВАЛЮТА,КОД_ФИЛИАЛА,НОМЕР_СЧЕТА)

также таблица ПРОВОДКА(ID,ID_СЧЕТА_ДЕБЕТА,ID_СЧЕТА_КРЕДИТА,СУММА)

как думаете если я атрибуты СЧЕТА: ВАЛЮТА,КОД_ФИЛИАЛА добавлю в таблицу проводки "дублированием" запрос будет выполняться быстрее ?

1.
Select Д.ID СЧЕТА_ДЕБЕТА
,Д.НОМЕР_СЧЕТА_ДЕБЕТА
,Д.ВАЛЮТА_ДЕБЕТА
,Д.КОД_ФИЛИАЛА_ДЕБЕТА
,К.ID_СЧЕТА_КРЕДИТА
,К.НОМЕР_СЧЕТА_КРЕДИТА
,К.ВАЛЮТА_КРЕДИТА
,К.КОД_ФИЛИАЛА_КРЕДИТА
,П.СУММА
from ПРОВОДОК П
,СЧЕТА Д
,СЧЕТА К

WHERE П.ID_СЧЕТА_ДЕБЕТА=Д.ID
AND П.ID_СЧЕТА_КРЕДИТА=К.ID

2
Select П.ID СЧЕТА_ДЕБЕТА
,П.НОМЕР_СЧЕТА_ДЕБЕТА
,П.ВАЛЮТА_ДЕБЕТА
,П.КОД_ФИЛИАЛА_ДЕБЕТА
,П.ID_СЧЕТА_КРЕДИТА
,П.НОМЕР_СЧЕТА_КРЕДИТА
,П.ВАЛЮТА_КРЕДИТА
,П.КОД_ФИЛИАЛА_КРЕДИТА
,П.СУММА
from ПРОВОДОК П

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

NafБакыт,

так Вы раздуете план счетов. Например, при наличии 5 валют и 20 филиалов у вас может быть 5*20=100 счетов, которые и отличаются только аналитикой.
Кроме того, не для всех счетов нужны эти признаки.
Наконец, вы все равно хотите дополнить этой аналитикой проводки, так зачем же эти признаки у самих счетов делать?
Не знаю как принято в Кыргызстане, но в РФ весь учет ведется в валюте РФ и только на некоторых счетах ( по у смотрению предприятия) может вестись учет в других единицах: валюте, количестве

у нас валютных операций много доллар и нац валюта почти 50/50


порождение проводок как автоматизировать ? для идентификации счета хранить в рабочих таблицах ?

а

Бакыт,

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

БредятинаБакытБакыт,

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

Dimitry SibiryakovxenixМне вот тоже интересно, что умные люди присоветуют
Например, забить на проводки, хранить только первичку и баланс считать непосредственно по ней.

еще вариант детализацию в первичке хранить проводки 1 суммой записывать не разрастается таблица проводок
а первичку по любому забиваем

БредятинаБакытпропущено...

как по вашему должно быть ?
Я написал ясно. Не должно быть такого типа сущности. Так как все операции итак есть. Смысла нет никакого ради балансовых счетов создавать еще один тип сущности, связывать его со всеми операциями (к тому же, в СУБД, которую Вы используете, связи в принципе не поддерживаются), причем, каждый конкретный экземпляр Проводки будет связан с экземпляром конкретной операции... Вы просто себе ответьте на вопрос - зачем это делать?))

как тогда формировать балансы,выписки по счетам, оборотное сальдо

выводить кучу аналитических отчетов ?

П-ЛТоварищ Бредятина в стремлении построить чистое и красивое здание с безупречными обводами не учитывает что делать его придется из обычных стройматериалов силами обычных работяг и в дальнейшем его как-то надо будет эксплуатировать. Если бы речь шла исключительно об управленческом учете, то основные сущности лежать в области операций/сделок/договоров, без проводок можно обойтись.

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

Чтобы предметно говорить о реализации нужно ДОСКОНАЛЬНОЕ знание банковских информационных процессов и собсвенно проектирования сложных систем. Ну и разумеется, собранные и формализованные бизнес-требования и функциональные требования для КОНКРЕТНОЙ задачи.

В этом топике от ТС кроме примитивнейшей картинки с куцей табличкой больше ничего нет. Каждый волен фантазировать в меру собственного опыта работы с банковско-бухгалтерской автоматизацией и булет прав.
как раз пусть фантазирует может что то получиться

может кто то подскажет из собственного опыта