Пришел к нам на работу ДБ девелопер, мне типа в помощь (зачем - непойму, вродеб и так справляюсь)

И начал толкать ООП подход ко всему, что в БД храниться...

типа

авторПонятие класса в базе данных: каждый класс соответствует таблице, запись таблицы является экземпляром класса. Каждый экземпляр класса должен однозначно идентифицироваться в таблице, поэтому в каждой таблице обязательно должно присутствовать поле – ключ объекта. В качестве ключа объекта очень желательно использовать целочисленное значение (суррогатный ключ). При этом данный ключ должен быть уникальным в пределах всей базы, а это значит, что для любого класса БД должен быть один общий предок, назовём его Object, а его ключевое целочисленное поле OID (Object IDentifier). Любой объект БД имеет текстовое наименование, по которому его идентифицирует пользователь в клиентском приложении, поле Name, а также каждый объект должен иметь поле, в котором хранится ссылка на его класс. В результате получаем:


авторДля наследника с дополнительными атрибутами необходимо создавать дополнительную таблицу с названием, соответствующим названию класса и обязательным наличием поля OID int not null primary key. По этому полю данные класса наследника соединяются с классом родителем один-к-одному. Создадим класс наследник Subject c дополнительными атрибутами Address (адрес субъекта) и OwnerOID (ссылка на вышестоящего субъекта-владельца, например для склада это компания). Любую ссылку на объект нужно именовать в нотификации <Атрибут>OID, дабы отличить ссылки на объект от обычных числовых или других идентификаторов.
авторКласс WorkGroup имеет атрибут-коллекцию, состоящую из списка пользователей, входящих в группу. В базе это реализуется в виде такой таблицы:



авторПри таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.

автор2. Наследование методов реализовано в базе данных


Или

И т.д и т.п.

Впервые если честно с таким встречаюсь... Все мозги запарил... Кто-нить встречался с таким? Как его отфутболить поумнее? Лажа ведь какая-то

Грит, при подходе с классами можно реализовать логику бизнес процесса... млин, в этот бред даже вникать неохота.

Max-xaMНапоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?

Я тебе по Мылу отвечу, в форуме не буду...

Ray Dну подход как похдод, видел и хуже :) единственное, что не надо его преподносить как единственно верный и пихать везде, где только можно.

вот вот... я только не пойму, как он собирается его продвигать в нашем проекте... а так может быть подход как подход

я ему уже задаю вопросики... насколько я понимаю, при ООП при каждом инсерте инсертить придется на самом деле в 2+ таблиц (типа в таблицу связи с родителями тоже)

Удалять и селектить то же самое... уже наводит тоску

pkarklin ShurgenzУдалять и селектить то же самое... уже наводит тоску

Ну, не все уж так тоскливо. Процедура вставки объекта будет содержать вызов процедуры вставки родительского объекта и INSERT в таблицу самого объекта.

На счет подхода - применим, но с умом. И не обязательно в контексте:

авторПри таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.

Может быть для справочных таблиц, в которых не так уж много записей.. А когда таблицы раздуты и они совсем немаленькие... Ведь для каждого объекта, чтоб выбрать информацию, нужно читать иногда из всех его родителей тоже, да + еще WorkGroup_Users - которая осуществляет многие-ко-многим меж ними... и помножить на степень наследования.

WiRuc pkarklin WiRucООП плохо ложиться на реляционную БД.

Ну, скажем так, я бы не стал называть приведенный подход "реализацией ООП в реляционной СУБД". IMHO, это некое развитие модели, создать одну таблицу документов на все возможные типы документов с кучей полей, допускающих NULL, или прикинуть, и создать некую модель (м.б. и напоминающей наследование) из нескольких таблиц с отношением 1-к-1 и полями NOT NULL.
По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.

И.... ссылка есть?