PostgreSQL: лучший способ создавать новые / дублировать существующие таблицы каждый год

Question

ссылаясь на на этот вопрос , я решил дублировать таблицы каждый год, создавая таблицы с данными года, например, как:

orders_2008
orders_2009
orders_2010
etc...

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

У этих таблиц будет даже какой-то дочерний элемент с внешним ключом; например, orders_2008 будет иметь дочерние элементы_2008:

CREATE TABLE orders_2008 (
    id serial NOT NULL,
    code character(5),
    customer text
);

ALTER TABLE ONLY orders_2008
    ADD CONSTRAINT orders_2008_pkey PRIMARY KEY (id);

CREATE TABLE items_2008 (
    id serial NOT NULL,
    order_id integer,
    item_name text,
    price money
);

ALTER TABLE ONLY items_2008
    ADD CONSTRAINT items_2008_pkey PRIMARY KEY (id);

ALTER TABLE ONLY items_2008
    ADD CONSTRAINT "$1" FOREIGN KEY (order_id) REFERENCES orders_2008(id) ON DELETE CASCADE;

Итак, моя проблема: как вы думаете, каков наилучший способ реплицировать эти таблицы каждый 1-й январь и, конечно же, сохранять зависимости таблиц?

Скрипт PHP / Python, который, запрос за запросом, перестраивает структуру на новый год (вызывается заданием cron)? Можно ли использовать функции PostgreSQL таким образом? Если да, то как (маленький пример будет хорош)

На самом деле я иду по первому пути (файл .sql, содержащий структуру, и скрипт php / python, загруженный cronjob, который перестраивает структуру), но мне интересно, если это лучший способ.

edit: Я видел, что функция pgsql CREATE TABLE LIKE, но внешние ключи должны быть добавлены во второй раз ... или она сохранит ссылки на новые таблицы на старую.

Answer 1

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

Answer 2

Вы должны посмотреть на Разделение в Postgresql . Это стандартный способ делать то, что вы хотите сделать. Он использует наследование, как предложил Джон Дауни.

Answer 3

Очень плохая идея.

Осмотрите разделы и следите за своей реальной целью :

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

Answer 4

Как уже упоминалось в вашем предыдущем вопросе, это, вероятно, плохая идея. Тем не менее, если вы намерены сделать это таким образом, почему бы просто не создать все таблицы заранее (скажем, 2008-2050)?

Answer 5

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

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