Здравствуйте! Я в проектировании абсолютно ничего не понимаю, больно пожалуйсто не пинайте. Я новичёек и вообще блодинко... (с)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))

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

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

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