Когда использовать наследованные таблицы в PostgreSQL?
В которых ситуациях необходимо использовать наследованные таблицы? Я пытался использовать их очень кратко, и наследование не походило в мире ООП.
Я думал, что это работало как это:
Таблица users который имеет все поля, требуемые для всех уровней пользователя. Таблицы как moderators, admins, bloggers, и т.д., но поля не проверяются от родителя. Например, users имеет почтовое поле и наследованный bloggers это имеет теперь также, но это не уникально для обоих users и bloggers в то же время. т.е. то же, поскольку я добавляю почтовое поле к обеим таблицам.
Только использование, о котором я мог думать, является полями, которые обычно используются, как row_is_deleted, created_at, modified_at. Действительно ли это - единственное использование для наследованных таблиц?
3 ответа
Есть несколько основных причин для использования наследования таблиц в postgres.
Допустим, у нас есть несколько таблиц, необходимых для статистики, которые создаются и заполняются каждый месяц:
statistics
- statistics_2010_04 (inherits statistics)
- statistics_2010_05 (inherits statistics)
В этом примере у нас есть 2 000 000 строк в каждой таблице. Каждая таблица имеет ограничение CHECK, чтобы гарантировать, что в ней хранятся только данные за соответствующий месяц.
Так что же делает наследование такой классной функцией - почему так здорово разделять данные?
- ПРОИЗВОДИТЕЛЬНОСТЬ: при выборе данных мы ВЫБИРАЕМ * ИЗ статистики WHERE date BETWEEN x и Y, а Postgres использует только таблицы, где это имеет смысл. Например. ВЫБРАТЬ * ИЗ статистики ГДЕ дата МЕЖДУ '2010-04-01' И '2010-04-15' сканирует только таблицу statistics_2010_04, все остальные таблицы не будут затронуты - быстро!
- Размер индекса: у нас нет большой толстой таблицы с большим жирным индексом на дату столбца. У нас есть маленькие таблицы в месяц, с маленькими индексами - более быстрое чтение.
- Обслуживание: Мы можем запускать вакуумное полное, переиндексирование, кластер для каждой таблицы за месяц без блокировки всех других данных
Чтобы правильно использовать наследование таблиц в качестве средства повышения производительности, посмотрите руководство postgresql.Вам необходимо установить ограничения CHECK для каждой таблицы, чтобы сообщить базе данных, по какому ключу ваши данные разделяются (секционируются).
Я активно использую наследование таблиц, особенно когда дело касается хранения данных журнала, сгруппированных по месяцам. Подсказка: если вы храните данные, которые никогда не изменятся (данные журнала), создайте или индексируйте с помощью CREATE INDEX ON () WITH (fillfactor = 100); Это означает, что в индексе не будет зарезервировано место для обновлений - индекс на диске меньше.
ОБНОВЛЕНИЕ: Коэффициент заполнения по умолчанию - 100, из http://www.postgresql.org/docs/9.1/static/sql-createtable.html :
Коэффициент заполнения для таблицы - это процентное значение от 10 до 100. 100 (полная упаковка) - значение по умолчанию
Единственный мой опыт работы с унаследованными таблицами - это разбиение на части. Он отлично работает, но это не самая сложная и простая в использовании часть PostgreSQL.
На прошлой неделе мы искали ту же проблему ООП, но у нас было слишком много проблем с Hibernate (не нравилась наша настройка), поэтому мы не использовали наследование в PostgreSQL.
Наследование можно использовать в парадигме ООП до тех пор, пока вам не нужно создавать внешние ключи в родительской таблице. Например, если у вас есть абстрактный класс vehicle, хранящийся в таблице vehicle, и таблица car, которая наследуется от него, все автомобили будут видны в таблице vehicle, но внешний ключ из таблицы driver в таблице vehicle не будет соответствовать этим записям.
Наследование можно также использовать как инструмент разделения. Это особенно полезно, когда у вас есть таблицы, которые будут расти вечно (таблицы журналов и т.д.).