Pull to refresh

Rails и полиморфные связи

Ruby on Rails *
В большинстве руководств по Rails, которые мне попадались в руки, в примерах по полиморфным связям есть интересная особенность выбора типа для этих связей, о которой и пойдет речь в этом посте.
Читать дальше
Total votes 28: ↑20 and ↓8 +12
Views 5.9K
Comments 24

Полиморфные связи

Ruby on Rails *
На днях в блоге Ruby on Rails появилась статья о полиморфных связях, в которой автор писал всякие разные вещи, но при этом забыл упоминуть, как их использовать и зачем они нужны (потом, конечно же, исправился, но все равно написал достаточно поверхностно).
Поначалу я даже испугался, что это моя статья каким-то непостижимым образом вырвалась из «черновиков» и попала в общую ленту. Потом разобрался, собрался с мыслями, и решил таки дописать свою.

Что же такое полиморфные связи и для чего они нужны? В одном из своих скринкастов Ryan Bates уже рассказывал об этом, и я ни в коем случае не хочу рассказывать то же самое. Ситуация была следующей:
у нас есть модели Статьи, Фотографии и События. А еще есть модель Комментарии. А еще очень хочется все комментарии (комментарии статей, фотографий и событий) хранить в одной таблице.
Статей по этой проблеме в интернете очень много, но бывают и случаи «наоборот». Далеко ходить не нужно, давайте попробуем разработать функционал постов Хабрахабра!
Читать дальше →
Total votes 58: ↑49 and ↓9 +40
Views 9.7K
Comments 37

Полиморфные связи для самых маленьких

PHP *System Analysis and Design *SQL *
Sandbox
Недавно, делая очередной функционал на одном из проектов, я столкнулся с немного необычными связями в реляционных СУБД, у которых, как оказалась позже, есть замысловатое название — Полиморфные связи. Что это такое, как и где их применять, я попытаюсь объяснить в данной статье.

Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.
Читать дальше →
Total votes 20: ↑15 and ↓5 +10
Views 59K
Comments 39

Как упростить доработки и поддержку хранилища данных?

System Analysis and Design *ERP-systems *Big Data *Data storages *Finance in IT
Sandbox

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

Проявления избыточной сложности в хранилищах данных можно перечислять долго. Это таблицы с сотнями полей, SQL-скрипты на тысячи строк, отдельные SQL-скрипты одинакового назначения для разных типов данных, отсутствие необходимой нормализации данных, отсутствие первичных ключей и ограничений целостности, отсутствие необходимых полей начала или окончания срока действия записи, наличие многочисленных и сложных «костылей», перекодировка или реклассификация данных, изменение типа или формата данных, замена идентификаторов, разнобой в наименованиях, излишнее количество слоев информационной системы, «протягивание» полей окольными путями, упаковка и распаковка составных полей, расчет лишних полей и использование лишних связей и условий, дублирование информации в записях и лишняя фильтрация записей, наследование таблиц, отсутствие единых правил заполнения данных.

Основной причиной избыточной сложности является денормализация в витринах данных. Популярное утверждение «денормализируйте, если необходимо повысить производительность» игнорирует проблему избыточной сложности, и поэтому во многих случаях неверно. Впрочем, источник цитаты это признает: «денормализованная база данных под большой нагрузкой может работать медленнее, чем её нормализованный аналог». Нетребовательность к структуре и качеству данных со временем неизбежно приводит к усложнению структуры данных и алгоритмов, ошибкам, замедлению работы информационных систем и раздуванию IT-подразделений.

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

Читать далее
Total votes 2: ↑2 and ↓0 +2
Views 2.7K
Comments 9