Зимаргл,
Ну вот смотри.
Есть, например, две таблицы (извиняюсь за условный язык) и UDF
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE SalesHeader{
DocN STRING;
Buyer STRING;
...
PostIt(inDate DATETIME);
}KEY uniqDocN (DocN)
CREATE TABLE SalesHeader
{ DocN STRING;
Art SRTING; //foreign key
Qty INTEGER;
}KEY uArt (DocN,Art);
CREATE FUNCTION DoPost(DocN STRING)....
Классический случай нормализации документа, плюс функция, которая учитывает отдельные документы. Но в БД все валяется по отдельности и пользователь должен в голове держать, что эти три фигни по факту относятся к одной бизнес -сущности, к одному документу.
Вместо этого можно использовать что то типа
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CREATE CLASS Sales{
DocN STRING; //Scalar attr.
Buyer STRING;// Scalar attr.
...
Items SET OF //Table attr.
{ Art GOODS; //Reference
Qty INTEGER;
}KEY uArt (Art); //Table field key
PostIt(inDate DATETIME); //Method
}KEY uniqDocN (DocN)//Class key
По факту я сообщаю СУБД инфу, достаточную для того, что бы СУБД сама унтутри создала эти две таблицы и хранимку. Но, при этом, я сообщаю ей, что все это относится к одной сущности, поэтому она может там унутри поступать хитрее, например, для того, что бы не джойнить записи из двух таблиц (как это следует из теории), а как то их в ОЗУ ссылками один раз и навсегда связывать при загрузке, или вообще хранить на диске объекты целиком, а при чтении в память их заоодно по условным табличным буферам раскидывать и тп. В общем всё это скрыто, всё это соответствует теории (по которой типа выполняется JOIN). Самое главное, пользователь работает с такими объектами, имея такую сложную сущность в схеме своей БД, поэтому для него схема БД выглядит гетерогенной, в смысле такие объекты и старые таблицы рядом.
Надо учитывать, что такая схема класса требует в дальнейшем полной реализации, пи этом любой атрибут может храниться или вычисляться.
