Работа с дублированными данными в SQL Server

Question

У меня есть большая таблица SQL-сервера, которая выглядит примерно так:

ImageId int
Page int
FSPath varchar(256)
ImageFrame int
...

В таблице хранится запись для каждой страницы ряда файлов изображений. Это делается для того, чтобы таблица могла представлять изображения, где каждая страница представлена ​​отдельным файлом, и файлы многостраничных изображений, которые содержат страницы в одном и том же файле. Когда я имею дело с многостраничной настройкой, значение столбца FSPath точно дублируется для каждой страницы в одном и том же документе, который занимает много места (одна эта таблица в настоящее время составляет ~ 5 ГБ). Кажется очень расточительным дублирование данных таким образом, но я не смог найти альтернативное решение, которое меня устраивает.

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

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

Я надеялся, что смогу создать обновляемое представление объединенных таблиц и позволить SQL Server сделать магию для меня, но я получаю сообщение: представление или функция 'Scrap.dbo.PageView' не могут быть обновлены, потому что изменение влияет на несколько базовых таблиц. Попытка выполнить вставку.

Есть ли разумный способ сделать это, что я просто скучаю или мне не повезло?

Answer 1

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

Как выглядит файловая система? Если это глубокое дерево каталогов, есть ли способ абстрагировать это в отдельную таблицу поиска, вместо того, чтобы каждый раз сохранять информацию о пути? Например, что-то вроде:

Таблица ПУТИ:

ID    PATHNAME        PARENT
int   varchar(128)    int, FK on PATHS.ID
---   ------------    --------------------
1     /               NULL
2     images          1
3     dir1            2
4     dir2            2

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

ID    PATHNAME
int   varchar(128)
---   ------------
1     /
2     /images
3     /images/dir1
4     /images/dir2

Тогда вы можете изменить определение вашей таблицы на:

ImageId int
Page int
FileName varchar(256)
Path int, FK to PATHS.ID
ImageFrame int
...

и, возможно, сэкономить немного места, особенно если оно очень глубокое.

Answer 2

Я смущен фактической проблемой? У вас проблемы с производительностью или 5 гигов действительно так дорого? Если производительность - проблема, меньшая таблица может не быть решением. Я бы исследовал изменение FSPath на char (256). Это займет больше места, но ваши данные будут лучше размещаться на жестком диске, и должно повысить производительность. Я также поддержал бы изменение схемы, как вы описали, но если это невозможно, потому что потребители не могут / не будут изменять код, вам, возможно, придется построить какой-то тест, чтобы показать, что изменение того стоит.

Answer 3

Я думаю, что вы правы - создание новой таблицы только для хранения уникальных путей может фактически занять больше места, чем оставить дублированные данные в исходной таблице. Плюс это усложняет запросы и обновления. Это зависит от количества дубликатов, конечно.