Производительность MySQL / Rails: одна таблица, много строк против многих таблиц, меньше строк?

В моем приложении Rails есть несколько моделей, связанных с активами (вложения, изображения, логотипы и т. Д.). Я использую attachment_fu, и пока у меня есть 3 разных таблицы для хранения информации в моей базе данных MySQL.

Мне интересно, влияет ли это на производительность, если я использую STI и помещаю всю информацию всего в одну таблицу, используя столбец типа и имея разные унаследованные классы. Он был бы более СУХИМ и проще в обслуживании, потому что все они имеют много общих атрибутов и характеристик.

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

Спасибо за ваше мнение!


mysql ruby-on-rails performance single-table-inheritance
person Ole Spaarmann    schedule 28.04.2009    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Многие таблицы и меньше строк, вероятно, быстрее.

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

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

Он медленнее, более хрупкий, умножит ваш код на все приложение и сделает плохую модель.

Сделайте это только, если все объекты имеют одинаковые атрибуты и одинаковое (или, возможно, заменяемое Лисковское) семантическое значение в вашей проблемной области.

В противном случае даже не пытайтесь это сделать.

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

person tpdi    schedule 28.04.2009

arrow_upward
2
arrow_downward

Единственный способ узнать наверняка - попробовать оба подхода и измерить производительность.

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

person John Topley    schedule 28.04.2009

arrow_upward
0
arrow_downward

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

person Nadj    schedule 16.03.2011