Comments 9
Чем нарисованы такие прекрасные картинки?
dbdsgnr.appspot.com/app вот тут рисовал, а потом Ножницы в Windows.
Если уж говорить про инструменты, то есть такая замечательная штука как Power Architect. Основная прелесть в том что она умеет делать reverse
>> Переделывать схему можно, но возрастает избыточность, которую нужно поддерживать в корректном состоянии.
Не совсем понял, почему возрастает избыточность? С точки зрения БД вроде все в рамках третьей нормальной формы находится.
Не совсем понял, почему возрастает избыточность? С точки зрения БД вроде все в рамках третьей нормальной формы находится.
Получается такая ситуация (по второму рисунку): появляется дополнительное поле type, поле type_id никуда не пропадает. Получается что два поля идентифицируют сущность. Если тип контакта изменится, то нужно будет изменить и имя класса.
Но основное условие было постараться максимально меньше внести изменений в существующую структуру.
Но основное условие было постараться максимально меньше внести изменений в существующую структуру.
Может, стоило бы поле type поместить в ContactType, а не в Contact?
А зачем? Там есть поле name, на основе которого можно вычислить класс.
Для чего тогда вообще нужно поле type? Только чтобы при выборке из таблицы Contact не джоинить с ContactType?
Я б сформулировал иначе: чтобы использовать штатную реализацию STI. Поле может называться как угодно, но оно обязано указывать на существующий класс, либо быть пустым и находится в тойже таблице. В моем случае данное поле заменяю на join с другой таблицей и получение имени класса оттуда. Штатными средствами реализовать не получилось такую схему.
Sign up to leave a comment.
Неканоническое STI в Rails