Тут вот столкнулся с тем что для моего проекта более всего подходит EAV модель.
Необходимо как можно больше информации по этой вот модели.....

Описание модели:
http://ycmi.med.yale.edu/nadkarni/eav_CR_contents.htm

YBW тут проблема в том что необходимо хранить классы и объекты. Но при этом классов очень много, что вызывает необхдимость в динамической структуре у базы... А ООСУБД требуют компиляции классов и, как следствие, получается жёсткая структура... Если у кто ещё чего подскажет, то буду рад...

4321 ModelRКак будет работать с классами приложениеесли "класс" это "разновидность" [род] _сущностей_ (в некоторой классификации (а не "объектные мордосы", как их понимает ООП), то да, для работы приложения с ними нужны некие мордосы. Но совсем не обязательно специализированно-компильнутые. Вполне сойдут и обабщенные (вполне возможно - "программно-настраиваемые" с помощью дополнительных "мордатых" метаданных). Вопрос лишь в полноте "обабщения" мордосов и в полноте структуры метаданных для настройки их (мордосов) поведения. (пынятно, чтаа обопщенный морд тяжелее специализированного, ну дык - це ж плата за общность).

Нет?
Типа того, класс - это класс при классификации, далее идут подклассы, ну а потом объекты. При чём объектов в конечном подклассе не более сотен, обычно даже десятки. Зато классов огромное кол-во и вносится в базу они будут большим числом людей, за сим компиляция в принципе не возможна. Счас всё реализовано в ввиде свободных таблиц в dbf-формате, но с целостностью траблы. Ещё и связи между объектами надо прописывать, и, мало того хорошо бы связи с процедурами их обработки. Пока мне кажется привлекательной EAV-модель. Думаю процедурно реализовать в ней блокировки.
Вопрос просто, может кто что ещё подскажет....

ModelR modЗато классов огромное кол-во и вносится в базу они будут большим числом людей....Ещё и связи между объектами надо прописывать, и, мало того хорошо бы связи с процедурами их обработки. Связи в EAV не проблема, а вот огромное число классов...
Вам возможно понадобится система наследования и ролей. А также какие-то критерии, позволяющие пресекать неоправданное размножение классов, выявлять подозрительно похожие классы.
Согласен, может появится... Если операторы которые эти классы будут заводить намудрят
mumps
По поводу MUMPS думал, даже Cache смотрел- мерзость ещё та. Так нефига и не понял да и СУБД говорят плохая...

Легко:

Цитирую Ruslan2:
Cache - иерархическая(древовидная) СУБД на основе языка mumps,
имеет SQL и ОО обвязку.

Недостатки
1) не поддерживает консистентность транзакций (нельзя на ходу
получить согласованный отчет и т.п.) и, соответсвенно, не является
промышленной СУБД
2) реально не поддерживает кластеры и партиции
3) поскольку SQL и ООП - примочки, то имеются очень сильные
ограничения на их использование (например, не редактируется
план запроса)
4) нет системы разграничения доступа при работе с
б-деревьями (глобалями)
5) при всем при этом нереально стоит: от ~$200 за соединение
(для сравнения MS SQL Server MSDE - $0, Oracle - ~150 SE One)

Большинсво систем на Cache в РФ - это бывшие MSM-системы,
которые пришлось мигрировать на Сache. Поддерживаюся и
продвигаются старичками-фанатиками М-технологии.

ИМХО: Cache занимает нишу между Access и FB, но из-за нерациональной
ценовой политики потихоньку теряет долю рынка (рынок СУБД растет ~20% в
год, Сache ~5%). Так же иерарическая СУБД позволяет использовать
низкоквалифицированных т.н. программистов (старички, бывшие
элекронщики и пр.) и, в том числе ,за счет этого держится на плаву .

Может я с Rusla2 не во всём согласен. Но посмотри какой глухой форум по Cache... Если что спрашивал по Oracle, то отвечают... В форуме Cache фиг что-то вразумительное ответят. Хотя ребята из Intersystems приветливые... Книжка по Cache 5 вышла 5 лет назад, а на русском появилась тока летом, причём переводчик тот-же что и по 4 версии, часть материала один в один, хотя часть совсем другая... И это среди любителей Cache было СОБЫТИЕ!!!!Мало того пишется в книге что язык, уже не помню какой из исопльзующихся в Cache, устарел, при этом почти все примеры в книге на нём, ановый язык даже не расскрыт.
Прикинь если так по Ораклу книги будут переводить?
За сим мерзость, хотя и на первы взгляд симпатично смотрится...

Роман ДынникЯ вам скажу что такая модель - это полная жопа.
Если есть желание загубить проект - реализуйте эту модель по сути из 3-х таблиц (объект-атрибут-значение), которую потом поддерживать кто-либо другой не сможет по тому что по ней нихрена ничего не видно что хранится внутри. Передо мной сейчас проект в котором подобная схема и реализована, да еще и на accesse, предыдущий чел сделал на этой модели зарплату (хватило же ума), наворотил дел и срулил, теперь вновь приходящий народ плюется, надо все переписывать с чистого листа, встретил бы его на улицы убил бы за это творение.
Это наихудший вариант объектной модели (из существующих трех) который можно реализовать. Никогда не берите его за основу!!! Он может существовать только как дополнение к нормальной реализации наследования на связях 1-к-1, union all, например для так называемых расширенных атрибутов (когда каждый тип товара имеет некоторые свойства, множество которых невозможно определить полностью на этапе проектирования).
Во-первых я реализую не на Access, а во-вторых никто напрямую с базой работать не будет. Для этого я разработал приложение, в котором выводится дерево классов(при помощи TreeView) и можно ддобавлять, удалять и редактировать классы, не подозревая как оно хранится, да и видно все связи по id в базе... Плюс я создал представление в которм всё видно...
Так что данной проблемы нет(для себя),а напрямую никто не должен ломится. В этом суть проекта.

Вобщем пока я понял что EAV единственный путь....

tertertertertertertertet удовлетворён?
Вообще MUMMPS как-то не модно нынче... А хранимые запросы как-то в моём случае тоже не удобно. Там ворде если юзать SQL, то надо хранить запросы на сервере и обращатся к ним по имени. При динамическом изменении структуры классов, как я буду запрсы на сервере хранить? OQL там нету, мол типа отстойный язык(это я в книжке прочёл), вот MUMPS и SQL форевер!!! SQL форевер, это да, но опять получится EAV, а на кой он мне в CACHE?
И ещё: в CACHE встрен Web-сервер, который по мнинию авторов той книжки, да и по информации из доков на диске к ниге, лучше не использовать для реальных проектов в качесвет Web-сервера, а тока для разработки...
Ну и нафига он такой недоделанный?
Вот в Oracle, например, без вапендрёжа Apache встроен, а не чтот-то своё оригинально не рабоающее, и всё путём...