А вот как я примерно поступил при аналогичном случае (в бух программе)
завел таблицу в кторой данные хранятся так (скокращенный вариант).
дата
Сумма
Количество
DS1
DS2
DS3
Debet
KS1
Ks2
KS3
Kredit
IdDoс

дата - дата проводки, сумма- суммовое выражение проводки, количество -- количественное выражение проводки, DS1 (KS1) - вещественная аналитика (т.е. отвечающая на вопрос ЧТО)
DS2 (KS2) - аналитика местоположения (т.е. отвечающая на вопрос ГДЕ (УКОГО от кого)), DS3 (KS3)- аналитика основания (т.е. отвечающая на вопрос на основании ЧЕГО), IDdoc- иддокумента породившего эту запись
Вот пример складского движения (т.е. передаем ВИЛЫ (ОТВЕЧАЕТ ВОПРОС ЧТО) со СКЛАДА (ОТВЕЧАЕТ НА ВОПРОС ОТКУДА)на отдел (сотрудника) ОТВЕЧАЕТ НА ВОПРОС КУДА)



дата -01,01,2006
Сумма -100
Количество - 5
DS1 - ВИЛЫ
DS2 - сотрудник (отдел)
DS3 - 'ПУСТО' хотя можно например учтиывать из какого счета фактуры (для партионного учета) передаются ДАННЫе ВИЛЫ
Debet - 10.1
KS1 - ВИЛЫ
Ks2 - СКЛАД
KS3 - 'ПУСТО' хотя можно например учтиывать из какого счета фактуры (для партионного учета) передаются ДАННЫе ВИЛЫ
Kredit - 10.1
IdDoс - код документа ПЕРЕМЕЩЕНИЯ

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

Bogdanov Andrey LamazoidА вот как я примерно поступил при аналогичном случае (в бух программе)
завел таблицу в кторой данные хранятся так (скокращенный вариант).

Из вашего примера совсем непонятно, как по значению того, что находится в поле DS2 понять что же это такое - сотрудник, склад, отдел или еще что-то. У вас должен быть либо единый классификатор всех объектов (то есть тот случай, который я приводил), либо вместе с полем DS2 в таблице проводок должно быть еще одно поле, описывающее тип ссылки, а у самого поля DS2 ссылка неспецифицирована.
Наверное придется описывать подробно... Код объекта (сотрудника , подразделения, материала... )уникален - в пределах всей системы -это раз далее написан запрос на объединение типа (упрощенно)
SELECT FIO as НАименование, кодсотрудника AS Код FROM сотрудники
UNION ALL
SELECT Otdelname,кодотдела AS Код FROM otdels
UNION ALL
SELECT НАименованиеКонтагента,кодКонтагента AS Код FROM контрагенты
- затем уже этот запрос цепляется к таблице движения по полю DS2 И KS2 и вот результат: все телодвижения видны. Аналогичный запрос по материалам (основные средства, коды затрат на производстве, материалы с услугами)
канечна для разных отчетов этот запрос с разным набором полей

к сож недостаток такого хранения - жесткая завязка что в каком поле хранится (DS1, KS1 - не может хранить подразделения и т.д.) но счас веду разработки - где пользователь вообще сам решает где и что хранить

Bogdanov Andrey LamazoidКод объекта (сотрудника , подразделения, материала... )уникален - в пределах всей системы -это раз далее написан запрос на объединение типа (упрощенно)

Ну как я и сказал у вас есть единый классификатор объектов. Просто он не материализован в виде таблицы СУБД. Видимо вы проверку уникальности идентификаторов делаете вне СУБД-шным образом. Или вообще не делаете, полагаясь на, например, Oracle-овый sequence. Это конечно хорошо, но обычный unique-констрейнт понадежнее будет.
Так оно и есть как в оракле (тока у меня ms скюэл+ аксес): написал функцию увеличивающую содержимое таблицы "А" на единицу и возвращающую это значение. А насчет надежности или нет -это предмет споров не очем поэтому каждый выбрает что-либо свое.

Изопропил
GUID не рассматривали вместо счётчика?
Я еще тот акцесист а там текстовые иннер джоины по GUID почемуто работаю несколько медленнее
чем по числовому - фиг знает почему. вот я по превычке и сделал обычный счетчик - еще это помогло обойтись без еще одной проблемы при переходе с акса на скюл+акс