Рубин динамически привязан к столу

Question

У меня огромный монстр базы данных (хорошо, это не совсем так, но в одной таблице продуктов более 8 миллионов записей) .. Эта таблица снабжена 13 поставщиками. Даже с наилучшей индексацией, которую я смог придумать, поиск 10000 лучших записей, готовых для поставщика 8, сумасшедшая медлительность. Я хотел бы создать таблицу продуктов для каждого поставщика и разбить таблицу на меньшие таблицы.

Теперь в c ++ или что там у вас, я бы просто переключил таблицу, с которой я работаю, внутри класса.

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

---

Ох .. 8 миллионов и вырастет до 20 миллионов в следующие 6 месяцев.

Был задан вопрос, какой у меня движок БД ... Сейчас это sql, но я открыт для переноса моей БД на другой движок, если это будет означать, что я могу использовать временные таблицы и таблицы с разделами. *

---

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

Answer 1

Под Ruby я предполагаю, что вы имеете в виду наследование от класса ActiveRecord :: Base в приложении Ruby on Rails.По соглашению, вы правы в том, что каждый класс должен представлять отдельную таблицу.

Вы можете легко выполнить произвольный SQL, используя метод " ActiveRecord :: Base.connection.execute ",и передать строку, которая является вашим запросом SQL.Это позволит обойтись без создания отдельных классов Ruby, которые будут представлять временные таблицы.Это не «подход Rails», однако он решает ваш вопрос о разрешении переключения таблиц внутри файла класса.

Более подробную информацию об операторах базы данных ActiveRecord можно найти здесь: http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/DatabaseStatements.html

Однако, как отмечали другие люди, вы должны иметь возможность оптимизировать свой запрос так, чтобы разделение по нескольким таблицам не требовалось.Вы можете проанализировать план выполнения вашего SQL-запроса, используя различные инструменты для оптимизации выполнения.Если вы используете представление MySQL, ознакомьтесь с их функциями планирования выполнения запросов: http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html

Путем введения индексов или изменения методов соединения между таблицами и т. Д. Вы сможете вернуться, чтобы сократить время выполнения запроса.