Что-то вроде подсчета ссылок или общих указателей для строк базы данных?

Question

Прежде всего, я использую Postgres 9.1.

У меня есть таблица с именем filepaths и другие таблицы, в которых есть строки, указывающие на идентификатор соответствующих файловых путей. Существует ли общий метод проектирования для подсчета ссылок на пути к файлам, чтобы при удалении других строк и отсутствии ссылок на конкретную строку пути к файлу он также мог быть удален?

Пример:

    [filepaths]
    1 | c:\windows\system32\test.exe
    2 | c:\windows\calc.exe

    [events_2011_08_30]
    [1][timestamp][other data] [ filepaths = 1]
    [2][timestamp][other data] [ filepaths = 2]

    [events_2011_08_31]
    [1][timestamp][other data] [ filepaths = 1]

Поэтому я буду хранить данные в таблицах для их разбиения, и я хочу удалить старые таблицы, если они старше, чем, скажем, 30 дней (все равно они будут заархивированы). В приведенном выше примере давайте предположим, что есть только эти две таблицы events_. Если я удалю 2011_08_30, я хотел бы узнать, что ничто не указывает на пути к файлам '2', и, следовательно, удалить его, но знать, что строка все еще указывает на пути к файлам '1', и, следовательно, сохранить его.

Есть мысли, предложения и т. Д.? Я полагаю, что некоторые из стратегий, которые я прочитал, по крайней мере для postgres и триггеров, все еще имеют условия состязания о том, какой поток сначала получил блокировку для столбца первичного ключа и другие связанные с этим проблемы.

Спасибо!

Answer 1

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

С точки зрения подсчета ссылок на filepaths, это может быть выполнено несколькими способами, но для обеспечения инкапсуляции кода я бы рекомендовал один из следующих двух подходов ...

1. API хранимых процедур

Убедившись, что все операции INSERT, UPDATE и DELETE обрабатываются с помощью хранимых процедур, вы также можете инкапсулировать приращение и уменьшение счетчика ссылок на filepaths. Пользователю / логину не требуется доступ к таблицам для операций записи, вместо этого они просто используют хранимую процедуру.

2. Триггеры

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

Многие люди уклоняются от триггеров, поскольку чувствуют, что они спрятаны, и могут иметь сложные взаимодействия при чрезмерном использовании. Я, однако, думаю, что они чрезвычайно полезны.

В любом случае все НАМНОГО упрощается, если иметь только одну таблицу, а не несколько таблиц.

Кроме того, большинство шаблонов SQL Design не учитывают «удаление таблицы» как действие «Бизнес как обычно». Создание или удаление таблиц, на мой взгляд, должно рассматриваться как изменение дизайна, а не как обработка данных.

Answer 2

Вам не нужен подсчет ссылок.(вы можете реализовать это с помощью триггеров, если вы действительно хотите этого) То, что вы хотите, называется внешним ключом [ограничение]

Самый простой способ очистить таблицу filepath - использоватьКонструкция НЕ СУЩЕСТВУЕТ, например,

DELETE FROM filepaths fp
WHERE NOT EXISTS ( SELECT * FROM events ev where ev.file_id = fp.file_id)
AND NOT EXISTS (SELECT * FROM events_version_xxx ev where ev.file_id = fp.file_id)
AND NOT EXISTS (SELECT * FROM events_version_yyy ev where ev.file_id = fp.file_id)
...
;

Это ужасно.Но модель базы данных тоже ужасна.