Неканоническое STI в Rails

[raskumandrin]

Чем нарисованы такие прекрасные картинки?

[fuCtor]

dbdsgnr.appspot.com/app вот тут рисовал, а потом Ножницы в Windows.

[norguhtar]

Если уж говорить про инструменты, то есть такая замечательная штука как Power Architect. Основная прелесть в том что она умеет делать reverse

[ivs13]

>> Переделывать схему можно, но возрастает избыточность, которую нужно поддерживать в корректном состоянии.

Не совсем понял, почему возрастает избыточность? С точки зрения БД вроде все в рамках третьей нормальной формы находится.

[fuCtor]

Получается такая ситуация (по второму рисунку): появляется дополнительное поле type, поле type_id никуда не пропадает. Получается что два поля идентифицируют сущность. Если тип контакта изменится, то нужно будет изменить и имя класса.

Но основное условие было постараться максимально меньше внести изменений в существующую структуру.

[ivs13]

Может, стоило бы поле type поместить в ContactType, а не в Contact?

[fuCtor]

А зачем? Там есть поле name, на основе которого можно вычислить класс.

[ivs13]

Для чего тогда вообще нужно поле type? Только чтобы при выборке из таблицы Contact не джоинить с ContactType?

[fuCtor]

Я б сформулировал иначе: чтобы использовать штатную реализацию STI. Поле может называться как угодно, но оно обязано указывать на существующий класс, либо быть пустым и находится в тойже таблице. В моем случае данное поле заменяю на join с другой таблицей и получение имени класса оттуда. Штатными средствами реализовать не получилось такую схему.