Comments 24
Да никаких подводных камней. Просто ActiveRecord унифицированная модель для нескольких БД. И не везде есть ENUM.
Конечно же, надо каждую табличку после стандартных миграций допиливать — добавлять индексы, внешние ключи, менять типы. Та же ситуация не только с полиморфными связями, но и с STI
Конечно же, надо каждую табличку после стандартных миграций допиливать — добавлять индексы, внешние ключи, менять типы. Та же ситуация не только с полиморфными связями, но и с STI
Если бы вы добавили краткую аннотацию, что такое полиморфные связи, зачем они нужны и в чём преимущество их использования, мне кажется статья стала бы полнее и полезнее.
В самом деле. Добавлю.
у меня сейчас в черновиках валяется статья, уже пару дней тружусь, именно про то, что такое полиморфные ассоциации и как их использовать. Поначалу даже подумал, что это моя статья каким-то образом появилась в общей ленте:) Знатно испугался, знаете ли:)
Более наглядно результаты выглядили бы на графике
UFO just landed and posted this here
А кто прокомментирует момент с изменением ENUM на большом количестве данных?
Спасибо за тесты.
Спасибо за тесты.
Поясните пожалуйста детальнее. Не совсем понятно что вы подразумеваете под изменением ENUM и о каком количестве данных идет речь?
Изменение схемы имеется ввиду, когда добавляется новое значение в ENUM, например.
Попытаюсь получить точные цифры. Если на глаз, то порядка 10 минут на 1000000 записей.
Обещанные данные:
1. ENUM -> VARCHAR — 1053.34708200 секунд
2. VARCHAR -> ENUM('Post','Image') — 535.87988500 секунд
3. ENUM('Post','Image') -> Enum('Post','Image','Something') — 826.80801800 секунд
на 1000000 записей.
1. ENUM -> VARCHAR — 1053.34708200 секунд
2. VARCHAR -> ENUM('Post','Image') — 535.87988500 секунд
3. ENUM('Post','Image') -> Enum('Post','Image','Something') — 826.80801800 секунд
на 1000000 записей.
Что-то неоднозначные соотношения в результирующей таблице наводят на мысли о неодинаковости наборов исходных данных. Надо было одним скриптом оба варианта заполнять, чтобы все посты в обоих случаях имели одни и те же комментарии.
P.S. В независимости от того какой вариант быстрее в реальности, нет смысла вводить ENUM пока в результате профайлинга реального приложения не доказано, что использование VARCHAR является узким местом в производительности.
Ибо преждевременная оптимизация — одно из самых больших зол в программировании.
P.S. В независимости от того какой вариант быстрее в реальности, нет смысла вводить ENUM пока в результате профайлинга реального приложения не доказано, что использование VARCHAR является узким местом в производительности.
Ибо преждевременная оптимизация — одно из самых больших зол в программировании.
Данные одинаковы в обоих таблицах. В подтверждение вот скрипт генерации gist.github.com/264003
Насчет преждевременной оптимизации, как мне кажется, речи не идет. Скорее тут вопрос проектирования БД. Разумеется можно оставлять VARCHAR, и потом по необходимости менять. Зависит от проекта и лично опыта.
Насчет преждевременной оптимизации, как мне кажется, речи не идет. Скорее тут вопрос проектирования БД. Разумеется можно оставлять VARCHAR, и потом по необходимости менять. Зависит от проекта и лично опыта.
Если я не ошибаюсь, то, что вы описываете в качестве альтернативы — это STI(Single Table Inheritance). Вообще вот здесь написано, что стоит использовать их не стоит, т.к. «модели будут связаны намертво» и потом их фиг отдерёшь друг от друга. Но вообще STI — иногда очень удобная штука, поэтому в каждом случае нужно решать отдельно, что вы будете использовать.
Sign up to leave a comment.
Rails и полиморфные связи