Здравствуйте! Я в проектировании абсолютно ничего не понимаю, больно пожалуйсто не пинайте. Я новичёек и вообще блодинко... (с)SQL.ru
Этот же вопрос я задал на sql.ru, но ответа так и не получил. Может вы подскажите.

Скажу упрощённо, ситуция такая, что под малыми кассами могут подразумеваться любые деньгохранилища, начиная от кошелька работника Васи и кончая кошельком работника Пети, потому, условно назовём это сборище "товариществом", вся работа товарищества сводится к тому, чтобы один у друго брал деньги и отдовал их следующему товарищу, таким образом обеспечивая движение денежных средств по кругу; конечно как и в каждом товариществе, здесь тоже есть председатель, как и каждый председатель, он хочет контролировать это самое движение денег (гы-гы, контролёр мля нашёлся), причём знать на любой момент у кого сколько денег, и не появилось ли среди товарищей сволочей и предателей, которые полученные деньги отдали следующему товарищу не сразу (про доверительные интревалы он мне лекцию из екселевского хелпа читал, аналитик мля), а то и, упаси боже, их присвоили.

Работают товарищи так — второй берёт у первого 50 долларов (проводка 1), завтра отдаёт третьему 45 (проводка 2), послезавтра берёт у первого 20 (проводка 3) и сразу отдаёт третьему 5 (проводка 4), на следующий день он берёт у первого 30 (проводка 5) и через день отдаёт 20 третьему (проводка 6), потом ещё 15 (проводка 7)..... Исходя из расчётов доверительных интревалов, надо узнать не злоупотребил ли втрой доверием и сразу ли отдавал все полученные деньги. И, если вдруг, сволочь такая, этого не делал, надо узнать по какой проводке он получил деньги, которые задержал и сколько времени их задерживал.

Вот тут и потребовалось мне сделать базу для председателя, в котрой бы осуществлялся контроль над оборатами денежных средств; воспользовавшись поиском, и, узнав что в бухалтерии существует метод файфа и прочие чудеса, такие как двойная запись и т.д. и т.п. (всех и не перечислить), а также, учитывая, что в нормальных базах данных бывает максимум одна-две таблицы, я сотворил сие чудо:

CREATE TABLE TovarschiTable(
    TovarischID        int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    ParentTovarischID    int,
    FileAsName        nvarchar(256))

CREATE TABLE ProvodkeesTable(
    ProvodkaID        int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    CrTovarischID    int NOT NULL,
    DbTovarischID    int NOT NULL,
    Suma            money,
    DateTime        datetime,
    CONSTRAINT FK_ProvodkeesTable_TovarschiTable_Credit
        FOREIGN KEY (CrTovarischID) REFERENCES TovarschiTable(TovarischID),
    CONSTRAINT FK_ProvodkeesTable_TovarschiTable_Debit
        FOREIGN KEY (DbTovarischID) REFERENCES TovarschiTable(TovarischID))

чудо сие, однако, к моему великому огорчению, отвечает лишь части поставленной задачи, она позволяет узнать остаток по любому товарищу, на любую дату, а так же его оборот и прочую абсолютно не нужную хрень(с); другая же часть задачи (при том основная часть), а имеено "Контроль над оборатами денежных средств", подразумевает, что объектом контроля являются не сами товарищи, а именно проводки.

Как вариант — вести партионный учёт денег (иными словами, когда манагер подписывает договор, и клиент получает эквивалент денег (в виде задолжности), номер договора и будет номер партии денег от которого и следует плясать? Бубен для плясок не подскажете где взять? — мне показался несколько бредовым, и как правильно заметил один товарищ "Это у вас деньги такие, что вы их партиями учитываете? Небось еще и себестоимость для каждой банкноты расчитываете... Увлекательная, должно быть игра — раскладываешь деньги кучками, и считаешь — вот в этой кучке бумажки из гастронома — учитываем по низшему коэффициенту, а эта кучка — прямо из банка, ставим максимальный... Круть!" что, в принципе, правильно.

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

Простите, я может не в том форуме вопрос задал?
Проектирования тут вроде нету...

Здравствуйте, бухой бык, Вы писали:

Из изложенного (что здесь что на sql.ru) весьма сложно понять, как же происходят движения средств и в чем их смысл. Что это вообще за бизнес такой?

Единствернное, что я смог уяснить (может и неверно), что в описанной модели невозможно определить, какие именно средства были "задержаны" и насколько. Для каждой отдаваемой "партии денег" нужно фиксировать, из каких (даже не какой!) полученных партий она сформирована. А это думаю не всегда сможет сказать и сам "товарищ". Это очень похоже на задачу покрытия задолженностей платежами, которая вроде успешно решается автоматически на основе правил. Ну или почти автоматически. Может и здесь можно применить.

Здравствуйте, wildwind, Вы писали:

Что за бизнесс? В принципе не важно. Нужен контроль над движением чёрного нала в малых кассах. Вот так грубо и открыто

Поясните, что значит "решается автоматически на основе правил" ?

бухой бык пишет:
> Простите, я может не в том форуме вопрос задал?
> Проектирования тут вроде нету...

Есть. "Архитектура программного обеспечения" называется.

Здравствуйте, Ромашка, Вы писали:

Р>бухой бык пишет:
>> Простите, я может не в том форуме вопрос задал?
>> Проектирования тут вроде нету...

Р>Есть. "Архитектура программного обеспечения" называется.

Мырдыратора, а не могли бы вы меня туда перенести? Или дублировать топег?

Здравствуйте, бухой бык, Вы писали:

ББ>Нужен контроль над движением чёрного нала в малых кассах. Вот так грубо и открыто :)

Нереально. IMHO. Т.к. невыгодно большинству участников.

ББ>Поясните, что значит "решается автоматически на основе правил" ?
Почитайте тут; может что прояснит. А может запутает.

Применительно к вашей задаче: описываются правила формирования этого покрытия. То есть от какой полученной партии (точнее ее остатка) сколько откусить, чтобы набрать требуемую сумму для передачи.

Здравствуйте, wildwind, Вы писали:

ББ>Нереально. IMHO. Т.к. невыгодно большинству участников.
Надо, Федя, надо...

ББ>>Почитайте тут; может что прояснит. А может запутает.
Читал там не совсем то...

ББ>>Применительно к вашей задаче: описываются правила формирования этого покрытия. То есть от какой полученной партии (точнее ее остатка) сколько откусить, чтобы набрать требуемую сумму для передачи.
это же чёрный нал какое там "описываются". Как то должно регистрироваться, и потом хитрым образом сверяться. Вот только каким?

Здравствуйте, wildwind:
немножко конкретики (по самое некуда упрощённо) —
Товарищ А получил ч заказ от третьего лица, получил аванс (дату можно отследить) и поехал к товарищу В. Говорит вот тебе 20 штук, сделай мне алюминевых штучек 3 тоны, 10 штук я те дам потом кошда со мной заказчик расчитается. Далее он едет к товарищу С и аналогично просит плассмасовых штучек за ту же сумму на тех же условиях. По идее товарищи В и С должны полученные деньги сразу сразу показать в ч бухалтерии, но они (сволочи) решили этими деньгами воспользоваться в своих подлых целях и на них наварицца. А председателю отдали их только когда получили окончательный ращет от товарища А (когда тот получил их от заказчика). И ввели это всё тепершним числом. В течении лдного "отчётного" периода таких "денгооборотов" может быть много. А председатель получает деньги один-два раза в течении этого самого "отчётного" периода за несколько "сделок" сразу.
Вот тут и требуется проконтролировать как двигалась партия денег которую получил председатель с самого момента её возникновения. Так сказать иерархически отобразить её появление и видеть, что-то в этом роде

председатель 2008.02.22 (100 штук)
|
|- товарищ В 2008.02.10 (30)
|  |
|  |- товарищ А 2008.01.15 (10)    
|  |  | 
|  |  |- третье лицо 2008.01.15 (10)
|  |   
|  |- товарищ А 2008.01.01 (20)    
|  |  | 
|  |  |- третье лицо 2008.01.01 (20)
|
|- товарищ В 2008.02.01 (30)
|
|  |- товарищ А 2008.01.15 (10)    
|  |  | 
|  |  |- третье лицо 2008.01.15 (10)
|  |   
|  |- товарищ А 2008.01.01 (20)    
|  |  | 
|  |  |- третье лицо 2008.01.01 (20)
|
|- товарищ С 2008.02.15 (40)
|  | 
|  |- третье лицо 2008.01.01 (40)

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