create TestTable
  {
    Id : Guid(pk);
    Zip : string?(len = 10) = "zzzz";
    Price : int = 10;
  }

   PersonId => Person;
   (f1, f2) => Person?; // несколько нулабельных колонок ссылаются на таблицу с композитным ключем
   
   PersonId :> Person;
   (f1, f2) :> Person?;

Z>   PersonId => Person;
Z>   (f1, f2) => Person?; // несколько нулабельных колонок ссылаются на таблицу с композитным ключем
   
Z>   PersonId :> Person;
Z>   (f1, f2) :> Person?; 
Z>

PersonId FK(Person);

H>Может лучше словами — FK, Assoc или что-то на тему.

Price : int = 10;

PersionId : fk Person;
(PersionId, OrderId) : fk PersonToOrders;
(PersionId, OrderId) : fk PersonToOrders?;
(PersionId, OrderId) : fk PersonToOrders(pk);

PersionId :> Person;
(PersionId, OrderId) :> PersonToOrders;
(PersionId, OrderId) :> PersonToOrders?;
(PersionId, OrderId) :> PersonToOrders(pk);

  create_table :taggings do |t|
    t.references :tag
    t.references :tagger, :polymorphic => true
    t.references :taggable, :polymorphic => { :default => 'Photo' }
  end

2. GORM: забавное название, серьезная технология

Эта часть посвящена другой области применения Grails: персистентности с использованием Grails Object Relational Mapping (GORM) API. Я начну с описания того, что такое объектно-реляционное отображение в Grails и с создания отношения один-ко-многим. Затем вы узнаете о проверках данных, гарантирующих, что ваше приложение не будет страдать синдромом «мусор на входе/мусор на выходе». Вы увидите язык предметной области GORM в действии, и он позволит вам настроить сохранение ваших POGO (plain old Groovy objects). Наконец, вы увидите, как просто переключиться с одной реляционной СУБД на другую. Подойдет любая СУБД, для которой имеется JDBC-драйвер и диалект Hibernate.

Определение ORM

Реляционные СУБД возникли в конце 70-х, но разработчики ПО по сей день бьются над эффективным извлечением и записью данных. Сегодняшнее ПО основано не на реляционных принципах, используемых в популярных СУБД, а на объектно-ориентированных.
Целый класс программ – ORM – служит для упрощения перемещения данных между БД и кодом. Hibernate, TopLink и Java Persistence API (JPA) – три популярные Java API, служащие этой цели (см. Ресурсы), хотя совершенным не является ни один из них. Проблема настолько персистентна (каламбур случайный), что имеет собственное крылатое выражение «объектно-реляционная несовместимость» (object-relational impedance mismatch, см. Ресурсы).
GORM – это тонкий Groovy-фасад над Hibernate. Это значит, что все ваши Hibernate-приемы будут работать – например, поддерживаются HBM файлы отображения и аннотации – но в этой статье речь пойдет об интересных возможностях самого GORM.

Создание отношения один-ко-многим

Легко недооценить сложности сохранения POGO в поля БД. На самом деле, если POGO отображается на одну таблицу, все довольно просто – свойства POGO точно соответствуют колонкам таблицы. Но если чуть-чуть усложнить объектную модель, например, ввести два POGO, ссылающихся друг на друга, все сразу станет намного сложнее.
Посмотрите, например, на Web-сайт Trip Planner, который мы начали в прошлой статье. Неудивительно, что POGO Trip играет в приложении важную роль. Откройте в текстовом редакторе grails-app/domain/Trip.groovy (листинг 1):
Листинг 1. Класс Trip

class Trip 
{ 
  String name
  String city
  Date startDate
  Date endDate
  String purpose
  String notes
}

Каждый из атрибутов в Листинге 1 легко и просто отображается на соответствующее поле таблицы Trip. В прошлой статье говорилось, что все POGO, которые хранятся в каталоге grails-app/domain, получают дополнительную таблицу, которая автоматически создается при запуске Grails. По умолчанию Grails использует встроенную БД HSQLDB, но к концу этой статьи вы сможете использовать любую реляционную СУБД по вашему выбору.
Поездка часто включает перелет, поэтому есть смысл создать класс Airline (показанный в листинге 2):
Листинг 2. Класс Airline.

class Airline
{ 
  String name
  String url
  String frequentFlyer
  String notes
}

Теперь вы захотите связать эти два класса. Чтобы запланировать перелет в Чикаго рейсом Xyz Airlines, вы представляете его в Groovy так же, как в Java-коде – добавляя в класс Trip свойство Airline (см. листинг 3). Эта техника называется композицией объектов (см. Ресурсы).
Листинг 3. Добавление свойства Airline в класс Trip.

class Trip 
{ 
  String name
  String city
  ...
  Airline airline
}

Все это здорово в программной модели, но в реляционных БД используется несколько иной подход. Каждая запись в таблице обладает уникальным ID, или первичным ключом. Добавление поля airline_id в таблицу Trip позволит связать одну запись с другой (в данном случае запись "Xyz Airlines" с записью "Chicago trip"). Это называется отношением один-ко-многим: с одной авиалинией может быть ассоциировано множество поездок (примеры отношений один-ко-многим и многие-ко-многим можено найти в онлайн-документации Grails, см. Ресурсы).
У предложенной схемы БД есть всего одна проблема. Вы можете иметь успешно нормализованную БД (см. Ресурсы), но теперь колонки таблицы рассинхронизированы с программной моделью. Если заменить поле Airline полем AirlineId, то вы допустите «просачивание» деталей реализации (факта сохранения POGO в БД) в объектную модель. Джоэль Спольски называет это Законом дырявых абстракций (см. http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html).
GORM помогает смягчить проблему дырявых абстракций, позволяя представить объектную модель способом, имеющим смысл для Groovy. Он скрыто занимается вопросами реляционной БД за вас, но, как вы сейчас увидите, можно легко переопределить настройки по умолчанию. GORM – это не непрозрачный слой, скрывающий от вас детали БД, а полупрозрачный – он пытается делать все правильно сам, но не встает у вас на пути, если вы захотите изменить его поведение. Это позволяет вам получить лучшее из двух миров.
Вы уже добавили свойство Airline в POGO Trip. Чтобы завершить отношение один-ко-многим, добавьте в POGO Airline настройку hasMany, как показано в листинге 4:
Листинг 4. Создание отношения один-ко-многим в Airline

class Airline 
{ 
  static hasMany = [trip:Trip]

  String name
  String url
  String frequentFlyer
  String notes
}

Каскадное удаление

В имеющейся модели вы можете получить «висячие» записи в БД: при удалении Airline останутся записи Trip, ссылающиеся на несуществующих родителей. Чтобы исключить это, можно добавить коллекцию типа hashmap static belongsTo в класс, описывающий сторону «многих».
Статическая настройка hasMany – это Groovy коллекция типа hashmap: ключ – это trip; значение – класс Trip. Если вы хотите создать еще одно отношение один-ко-многим для класса Airline, можно написать разделенный запятыми список пар ключ/значение в квадратных скобках.
Теперь создадим маленький класс AirlineController (см. Листинг 5) в grails-app/controllers, чтобы увидеть новое отношение один-ко-многим в действии:
Листинг 5. Класс AirlineController

class AirlineController 
{ 
  def scaffold = Airline
}

Вспомним из прошлой статьи, что def scaffold говорит Grails динамически во время исполнения создать базовые методы list(), save() и edit(). Он также говорит Grails динамически создать представления GroovyServer Page (GSP). И TripController, и AirlineController содержат def scaffold. Если после ввода grails generate-all у вас сохранились каталоги trip или airline в grails-app/views, их нужно удалить. В этом примере мы проверяем, что Grails создает контроллеры и представления динамически.
Теперь, когда доменные классы и контроллеры на месте, запустите Grails. Введите grails prod run-app, чтобы запустить приложение в рабочем режиме. Если все в порядке, вы увидите следующее сообщение:

Server running. Browse to http://localhost:8080/trip-planner

  create Person
  {
    Name      : string;
    Addresses : Association[Addresse]
//  описание можно задать и явно:
//  Addresses : Association[Addresse](1-many)
  }

  create Address
  {
    Country : string;
    City    : string;
    Street  : string;
    Hous    : string;
  }

  create Product
  {
    Name   : string;
    Price  : double;
    Orders : Association[Order]; // many-many, так как аналогичная ассоциация есть в Order
  }

  create Order
  {
    Date     : DateTime;
    Num      : string;
    Products : Association[Product]; // many-many, так как аналогичная ассоциация есть в Order
//  описание можно задать и явно:
//  Products : Association[Product](many-many)

    defkey[DateNum](Date, Num) : Unique; // описание уникального ключа (для него создается индекс)
  }

create Test
{
    id; // краткая запись для Id : Guid() = Sql.Newid;
    Text : string;
}

create Test
{
    noid; // если не указать это, то ключ будет сгенерирован
    Text : string;
}

Ассоциации

Ассоциациями называются связи между сущностями. Ассоциации задаются с помощью атрибутов и позволяют существенно упростить запросы за счёт того, что устраняют необходимость каждый раз указывать соединения между связываемыми таблицами.
Ниже приведена таблица Product и её ассоциации.

[TableName("Products")]
public abstract class Product
{
    [PrimaryKey, Identity] public int      ProductID;
    [NotNull]              public string   ProductName;
                           public int?     SupplierID;
                           public int?     CategoryID;
                           public string   QuantityPerUnit;
                           public decimal? UnitPrice;
                           public short?   UnitsInStock;
                           public short?   UnitsOnOrder;
                           public short?   ReorderLevel;
                           public bool     Discontinued;

    [Association(ThisKey="ProductID",  OtherKey="ProductID")]
    public List<OrderDetail> OrderDetails;

    [Association(ThisKey="CategoryID", OtherKey="CategoryID", CanBeNull=false)]
    public Category Category;

    [Association(ThisKey="SupplierID", OtherKey="SupplierID", CanBeNull=false)]
    public Supplier Supplier;
}

Что нужно знать об ассоциациях?
* Член класса, к которому применён атрибут ассоциации, может иметь либо списочный тип, либо являться ссылкой на объект. Списочный тип означает связь один-ко-многим. То есть в нашем случае имеется один Product и много Order Details. Просто ссылка на объект озна-чает связь один-к–одному, либо много-к-одному, что для нас уже не важно, т.к. на генера-цию SQL это никак не влияет.
* Сама связь задаётся парой свойств атрибута ThisKey/OtherKey. Свойство ThisKey пере-числяет через запятую поля самой сущности, в которой объявлена ассоциация. Свойство OtherKey – соответствующие поля связанной сущности. Если имена полей сущности и ис-ходной таблицы базы данных отличаются, то в этих свойствах указываются имена полей сущности.
* Свойство CanBeNull указывает BLToolkit, какую связь генерировать: Inner Join или Left Join. Будьте внимательны с этим свойством. Left Join, примененный не по делу, может весьма существенно увеличить время выполнения запроса. К тому же BLToolkit может произво-дить дополнительные оптимизации для связей один-к-одному и убирать лишние связи из запроса, если это Inner Join. В общем случае правило использования этого атрибута такое: для связей один-ко-многим CanBeNull может быть равно false только в случае, если мас-тер-запись не может появиться в базе данных без дочерних (например, Order -> OrderDetails); для связей один-к-одному CanBeNull чаще всего должно быть равно false, но это нужно указать явно.
* Члены класса, к которым применена ассоциация, не заполняются автоматически при чте-нии объекта из базы данных.
Теперь посмотрим, что у нас получилось:

from p in db.Product
select new
{
    p.Category.CategoryName,
    p.ProductName
};

Явное указание соединения (Join) с таблицей Category исчезло, но генерируемый SQL остался прежним:

SELECT
    [t1].[CategoryName],
    [p].[ProductName]
FROM
    [Products] [p]
        INNER JOIN [Categories] [t1] ON [p].[CategoryID] = [t1].[CategoryID]

Давайте попробуем поменять у ассоциации Category значение свойства CanBeNull на true и по-смотрим на результат:

SELECT
    [t1].[CategoryName],
    [p].[ProductName]
FROM
    [Products] [p]
        LEFT JOIN [Categories] [t1] ON [p].[CategoryID] = [t1].[CategoryID]

Теперь у нас получился Left Join.
Использовать списочные ассоциации можно, например, следующим образом:

from p in db.Product
select new
{
    p.OrderDetails.Count,
    p.ProductName
};

SQL:

SELECT
    (
        SELECT
            Count(*)
        FROM
            [Order Details] [t1]
        WHERE
            [p].[ProductID] = [t1].[ProductID]
    ) as [c1],
    [p].[ProductName]
FROM
    [Products] [p]

Как было сказано выше, связанные сущности не заполняются автоматически при создании объек-та, но при желании это можно сделать вручную:

from o in db.Order
select new Northwind.Order
{
    OrderID  = o.OrderID,
    Customer = o.Customer
};

SQL:

SELECT
    [o].[OrderID],
    [t1].[CustomerID],
    [t1].[CompanyName],
    [t1].[ContactName],
    [t1].[ContactTitle],
    [t1].[Address],
    [t1].[City],
    [t1].[Region],
    [t1].[PostalCode],
    [t1].[Country],
    [t1].[Phone],
    [t1].[Fax]
FROM
    [Orders] [o]
        INNER JOIN [Customers] [t1] ON [o].[CustomerID] = [t1].[CustomerID]

Ассоциации являются очень мощным средством, позволяющим с лёгкостью писать самые слож-ные запросы. Давайте попробуем написать запрос с многоуровневыми ассоциациями:

from o in db.OrderDetail
select new
{
    o.Product.ProductName,
    o.Order.OrderID,
    o.Order.Employee.ReportsToEmployee.Region
};

SQL:

SELECT
    [t1].[ProductName],
    [o].[OrderID],
    [t2].[Region]
FROM
    [Order Details] [o]
        INNER JOIN [Products] [t1] ON [o].[ProductID] = [t1].[ProductID]
        INNER JOIN [Orders] [t4]
            LEFT JOIN [Employees] [t3]
                LEFT JOIN [Employees] [t2] ON [t3].[ReportsTo] = [t2].[EmployeeID]
            ON [t4].[EmployeeID] = [t3].[EmployeeID]
        ON [o].[OrderID] = [t4].[OrderID]

Обратите внимание на то, что для разных таблиц используются разные типы Join. Это результат применения параметра CanBeNull.
Ещё одним интересным моментом является использования в Select поля OrderID из таблицы Or-derDetails, хотя в самом Linq-запросе используется поле таблицы Orders. Это как раз та самая оп-тимизация, которую выполняет BLToolkit, чтобы убрать лишние соединения. Давайте немного из-меним пример:

from o in db.OrderDetail
select new
{
    o.Product.ProductName,
    o.Order.OrderID,
    //o.Order.Employee.ReportsToEmployee.Region
};

SQL:

SELECT
    [t1].[ProductName],
    [o].[OrderID]
FROM
    [Order Details] [o]
        INNER JOIN [Products] [t1] ON [o].[ProductID] = [t1].[ProductID]

Так как таблица Orders для доступа к Employee нам теперь не нужна, а использование OrderID из OrderDetails не меняет логики запроса, то соединение с Orders тоже исчезло.
Кроме всего прочего, однотипные ассоциативные объекты разных сущностей можно сравнивать:

from o in db.Order
from t in db.EmployeeTerritory
where o.Employee == t.Employee
select new
{
    o.OrderID,
    o.EmployeeID,
    t.TerritoryID
};

SQL:

SELECT
    [o].[OrderID],
    [o].[EmployeeID],
    [t1].[TerritoryID]
FROM
    [Orders] [o], [EmployeeTerritories] [t1]
WHERE
    [o].[EmployeeID] = [t1].[EmployeeID]

И использовать для группировки:

from p in db.Product
group p by p.Category into g
where g.Count() == 12
select g.Key.CategoryName;

SQL:

SELECT
    [t1].[CategoryName]
FROM
    [Products] [p]
        INNER JOIN [Categories] [t1] ON [p].[CategoryID] = [t1].[CategoryID]
GROUP BY
    [t1].[CategoryID],
    [t1].[CategoryName]
HAVING
    Count(*) = 12

Для сравнения и группировки по объектам BLToolkit использует информацию о первичных ключах объекта. Если первичный ключ не задан, то BLToolkit генерирует код, сравнивающий все поля объекта друг с другом. Это, во-первых, неэффективно, а, во-вторых, не всегда возможно, т.к. не все типы в SQL можно сравнивать.
В качестве эксперимента давайте попробуем убрать у сущности Employee первичный ключ и вы-полнить предыдущий запрос ещё раз. В результате получится следующий SQL:

SELECT
  [o].[OrderID],
  [o].[EmployeeID],
  [t3].[TerritoryID]
FROM
  [Orders] [o]
    LEFT JOIN [Employees] [t1] ON [o].[EmployeeID] = [t1].[EmployeeID],
  [EmployeeTerritories] [t3]
    LEFT JOIN [Employees] [t2] ON [t3].[EmployeeID] = [t2].[EmployeeID]
WHERE
  [o].[EmployeeID] = [t3].[EmployeeID] 
    AND [t1].[LastName] = [t2].[LastName] 
    AND [t1].[FirstName] = [t2].[FirstName] 
    AND [t1].[Title] = [t2].[Title] 
    AND [t1].[TitleOfCourtesy] = [t2].[TitleOfCourtesy] 
    AND ([t1].[BirthDate] IS NULL
    AND [t2].[BirthDate] IS NULL 
  OR [t1].[BirthDate] IS NOT NULL 
    AND [t2].[BirthDate] IS NOT NULL
    AND [t1].[BirthDate] = [t2].[BirthDate])
    AND ([t1].[HireDate] IS NULL
    AND [t2].[HireDate] IS NULL
  OR [t1].[HireDate] IS NOT NULL
    AND [t2].[HireDate] IS NOT NULL
    AND [t1].[HireDate] = [t2].[HireDate])
    AND [t1].[Address] = [t2].[Address]
    AND [t1].[City] = [t2].[City]
    AND [t1].[Region] = [t2].[Region]
    AND [t1].[PostalCode] = [t2].[PostalCode]
    AND [t1].[Country] = [t2].[Country]
    AND [t1].[HomePhone] = [t2].[HomePhone]
    AND [t1].[Extension] = [t2].[Extension]
    AND [t1].[Notes] = [t2].[Notes]
    AND ([t1].[ReportsTo] IS NULL
    AND [t2].[ReportsTo] IS NULL
  OR [t1].[ReportsTo] IS NOT NULL
    AND [t2].[ReportsTo] IS NOT NULL
    AND [t1].[ReportsTo] = [t2].[ReportsTo])
    ANDы [t1].[PhotoPath] = [t2].[PhotoPath]

Мало того, что на этот запрос без слёз смотреть нельзя, так он ещё и не работает, так как среди полей таблицы Employees есть поля с типом ntext, которые нельзя сравнивать.
Будьте внимательны при описании модели данных. BLToolkit использует метаинформацию о сущностях для оптимизации запросов, и её отсутствие может привести к построению неоптимальных запросов.

Z>create Test
Z>{
Z>    id; // краткая запись для Id : Guid() = Sql.Newid;
Z>    Text : string;
Z>}
Z>

Z>create Test
Z>{
Z>    noid; // если не указать это, то ключ будет сгенерирован
Z>    Text : string;
Z>}
Z>

    drop Person.Addresses

  PersonId :> Person;

VD>Это потому что миграции меняют модель.

class Test
{
  mutable public F : string;
}

class Test
{
  mutable public F1 : string;
  mutable public F2 : string;
}