Кто-нибудь из присутствующих интересуется темой БЗ (KB), - в аспекте: как можно это реализовывать средствами MS Access?

"Хотим учитывать" информацию (знания) о ПРЕДМЕТНОЙ ОБЛАСТИ ... о ПРОИЗВОЛЬНОЙ предметной области: какие там, в этой предметной области, имеются объекты и предикаты, и отношения ... и какие эти предикаты (т.е. - свойства) имеют значения на (у) этих объектов ...

И, пожалуй, все это - в динамике, то есть - с учетом возможности изменения во времени и набора объектов, и значений предикатов, и отношений между объектами.

В общем ... стандартненькая такая постановочка ... задачки БЗ ... ;-)

Если Вы под словом "интерфейс" понимаете "все, что есть в СУБД, кроме самих табличек" ... то есть - ВСЮ ФУНКЦИОНАЛЬНОСТЬ, - то да: нужно всего-то "несколько табличек, с отношениями многие-ко-многим", да к ним в придачу - все остальное, что там понадобится ... всю РЕАЛИЗАЦИЮ задачи, в общем.

В этой терминологии - я как раз ищу людей, которые "интерфейс на чём угодно" для подобных задачек делали ... делают или собираются делать - конкретно средствами MS Access.

Хочется просто пообсуждать ДЕТАЛИ этого самого "интерфейса на чём угодно", - как его следует варганить, чтобы он был поэффективнее, да потехнологичнее ...

kedzo, сорри, я не понял: Вы хотите сказать, что эта задача нереализуема?
В смысле - никакой, даже самый плохоньнький - "интерфейс" БЗ на MS Access построить невозможно??

kedzo, Gyslik , - встречалась ли вам где-нибудь толковая реализация (и - толковое обсуждение реализации) подобной задачки?
Желательно все таки именно на MS Access ... почему? Потому, что задачка, на самом деле, совсем не простая, и понятно, что С++ (или, например, Oracle) для нее более адекватен, - как средство решения ... Но бывают ведь в жизни всякие разные ВНЕШНИЕ граничные условия ...

Хам трамвайный и "поддерживающий его полностью" Hummer , - как могут "во многих ТЕОРЕТИЧЕСКИХ книгах" быть "очень хорошо освещены" вопросы ПРАКТИЧЕСКОЙ реализации тех или иных задач? Да еще - с учетом ОГРАНИЧЕННОСТИ не самой мощной средой разработки??

kedzoа оракл использовать - у вас что так много данных будет?

- нуууу ... в оракле всякие-там триггеры водятся, у него ФУНКЦИОНАЛЬНОСТЬ более мощная, - вне зависимости от количества данных, правда?

и как вы определяете адекватность того или иного инструмента для решения непоставленной задачи?

- в каком месте у меня задача неДОпоставлена, сорри?

SharkТипа тебя умник:-)
- спасибочки, почитаю на досуге ... охотно готов допустить, что это даже окажется ПОУЧИТЕЛЬНО. (Вы ведь мне В ПОУЧЕНИЕ эту ссылку привели, правда?)

Shuhardпереходя к абстракциям - access РЕЛЯЦИОННАЯ СУБД
если для твоей задачи этот тип СУБД годиться - Acc не хуже других
Дык, для хранения значений никуда не деться от таблицы с тремя полями:
iRecord (Long), iField (Long), Value (это вот оно самое "значение" и есть!)

Эта таблица должна быть СВЯЗАНА с таблицами:
idRecord (Счетчик), ... (поля, идентифицирующие запись, в частности - iContext)
и
idField (Счетчик), FieldName (String), ... (поля, идентифицирующие Поле)

- значит, таки, задачка "реляционная" ...

ShuhardP.S. есть отдельная конфа по выбору СУБД - почитай её
- повторюсь, для меня выбор Acc - это ВНЕШНЕЕ ограничение.
Shuhardколи знаешь термины "предикаты"... "наборы" ...
- а кто же их не знает? ;-)
Shuhard- значит есть математический аппарат и следовательно есть работающие аналоги того,что ты хочешь построить - на чём аналоги написаны?
- есть, наверняка, мне лично, правда, не очень доступны ... И, опять повторюсь, задача мне видится не в том, чтобы что-то ИЗОБРЕСТИ, а в том, чтобы нечто более-менее понятное РЕАЛИЗОВАТЬ.

Shuhard2 Иван - т.е. язык SQL и реляционная модель Вас устраивает? - получается, что так ...
Shuhard автор
И, пожалуй, все это - в динамике, то есть - с учетом возможности изменения во времени и набора объектов, и значений предикатов, и отношений между объектамиспроэцируйте ,будьте так любезны, вышеозначенное в терминах ...
- если - как я уже писал, - "единица" хранения значений есть (iRecord,iField,Value), то временная динамика добавляется очень просто:

1. (iRecord,iField,Value,TimeStamp)
- в случае, если осмысленно варьирование-во-времени одного отдельно взятого поля записи,
или же

2. наличием поля? ... записи? ... "единицы хранения", в общем:
(iRecord,iField_of_TimeStamp,Value_of_TimeStamp)
- в случае, если варьирование-во-времени осмысленно только записи (которая iRecord) ЦЕЛИКОМ. (Этот метод кажется мне более правильным.)

А уже при "сборке" значений во view - мы будем/можем выбирать/указывать какие именно из TimeStamp должны быть задействованы ...