В большинстве руководств по Rails, которые мне попадались в руки, в примерах по полиморфным связям есть интересная особенность выбора типа для этих связей, о которой и пойдет речь в этом посте.
Полиморфные связи
На днях в блоге Ruby on Rails появилась статья о полиморфных связях, в которой автор писал всякие разные вещи, но при этом забыл упоминуть, как их использовать и зачем они нужны (потом, конечно же, исправился, но все равно написал достаточно поверхностно).
Поначалу я даже испугался, что это моя статья каким-то непостижимым образом вырвалась из «черновиков» и попала в общую ленту. Потом разобрался, собрался с мыслями, и решил таки дописать свою.
Что же такое полиморфные связи и для чего они нужны? В одном из своих скринкастов Ryan Bates уже рассказывал об этом, и я ни в коем случае не хочу рассказывать то же самое. Ситуация была следующей:
Поначалу я даже испугался, что это моя статья каким-то непостижимым образом вырвалась из «черновиков» и попала в общую ленту. Потом разобрался, собрался с мыслями, и решил таки дописать свою.
Что же такое полиморфные связи и для чего они нужны? В одном из своих скринкастов Ryan Bates уже рассказывал об этом, и я ни в коем случае не хочу рассказывать то же самое. Ситуация была следующей:
у нас есть модели Статьи, Фотографии и События. А еще есть модель Комментарии. А еще очень хочется все комментарии (комментарии статей, фотографий и событий) хранить в одной таблице.Статей по этой проблеме в интернете очень много, но бывают и случаи «наоборот». Далеко ходить не нужно, давайте попробуем разработать функционал постов Хабрахабра!
Полиморфные связи для самых маленьких
Sandbox
Недавно, делая очередной функционал на одном из проектов, я столкнулся с немного необычными связями в реляционных СУБД, у которых, как оказалась позже, есть замысловатое название — Полиморфные связи. Что это такое, как и где их применять, я попытаюсь объяснить в данной статье.
Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.
Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.
Как упростить доработки и поддержку хранилища данных?
Sandbox
Избыточная сложность хранилищ данных и связанных с ними информационных систем затрудняет проведение доработок, необходимых для интеграции систем или для удовлетворения новых требований, задерживает регулярную обработку данных, способствует появлению ошибок и мешает поиску их причин.
Проявления избыточной сложности в хранилищах данных можно перечислять долго. Это таблицы с сотнями полей, SQL-скрипты на тысячи строк, отдельные SQL-скрипты одинакового назначения для разных типов данных, отсутствие необходимой нормализации данных, отсутствие первичных ключей и ограничений целостности, отсутствие необходимых полей начала или окончания срока действия записи, наличие многочисленных и сложных «костылей», перекодировка или реклассификация данных, изменение типа или формата данных, замена идентификаторов, разнобой в наименованиях, излишнее количество слоев информационной системы, «протягивание» полей окольными путями, упаковка и распаковка составных полей, расчет лишних полей и использование лишних связей и условий, дублирование информации в записях и лишняя фильтрация записей, наследование таблиц, отсутствие единых правил заполнения данных.
Основной причиной избыточной сложности является денормализация в витринах данных. Популярное утверждение «денормализируйте, если необходимо повысить производительность» игнорирует проблему избыточной сложности, и поэтому во многих случаях неверно. Впрочем, источник цитаты это признает: «денормализованная база данных под большой нагрузкой может работать медленнее, чем её нормализованный аналог». Нетребовательность к структуре и качеству данных со временем неизбежно приводит к усложнению структуры данных и алгоритмов, ошибкам, замедлению работы информационных систем и раздуванию IT-подразделений.
Но можно значительно упростить доработки и поддержку хранилища данных, если придерживаться описанных далее правил.