Забота о производительности для общего механизма сохранения файлов

Question

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

FileInfo
=================================================================
ID   FileName   ContentType   FileSize   DatabaseTableName  RowID

и создание следующей таблицы с OneToOne отношения, чтобы сохранить данные файла в отдельной таблице, так что запрос FileInfo Таблица может быть выполнена быстрее:

FileData
=================================================================
ID  FileData

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

И если это произойдет, не могли бы вы дать мне лучшее решение?

заранее спасибо

Answer 1

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

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

Капли в базе данных вызывают определенные недостатки. Неважно, где живут эти капли.

Мне нравится разделение на две таблицы, как вы сделали это. Обычно это не обязательно. Если запросы правильно написаны и извлекают только необходимые столбцы, SQL Server вообще не будет касаться неиспользуемых столбцов больших двоичных объектов.

Тем не менее, часто удобно разделять большие капли, как и вы. ОРМ не любят огромных рядов. Инструменты (и администраторы работают с простым руководством select *) теперь могут заглянуть в FileInfo таблица без сбоев из-за больших данных.

Разделение не обязательно, но может упростить работу с базой данных.