Где я должен сохранить фотографии? Файловая система или база данных? [дубликат]
Это не может быть сделано в LINQ2SQL с отдельным оператором как синтаксис LINQ, и дополнительные методы не поддерживают, вставляет. Следующее (принимающий datacontext, названный db), должно добиться цели.
if (!db.Users.Any( u => u.UserName == "michael" ))
{
db.Users.InsertOnSubmit( new User { UserName = "michael" } );
db.SubmitChanges();
}
10 ответов
Файловая система, конечно, если вы не хотите написать историю на thedailywtf. Самый простой способ - организовать фотографии по свойству, которое вы можете получить из самого файла, например по его хэшу SHA-1. Затем просто сохраните хэш в базе данных, прикрепив его к первичному ключу фотографии и другим атрибутам (кто их загрузил, дату загрузки и т. Д.).
Также неплохо разделить фотографии в файловой системе, чтобы не делать этого. в итоге миллионы файлов находятся в одном каталоге. У вас будет что-то вроде этого:
Если вы используете SQL Server 2008, существует тип данных Filestream, который решает большинство проблем, упомянутых в увеличении размера БД. Он обрабатывает все раздражающие детали синхронизации между файловой системой и таблицей.
Посмотрите здесь сообщение в блоге на эту тему: Храните любые данные в SQL Server 2008 (Katmai)
Если вы создаете веб-сайт на основе фотографий, забудьте о базе данных. Если он станет популярным, ваша база данных сильно пострадает, и большая часть ее времени будет тратиться на доставку фотографий. Также базы данных не очень хорошо масштабируются. Хранение их в файловой системе дает гораздо больше преимуществ. И вы можете очень хорошо масштабироваться, имея серверы статического контента, используя сервисы для доставки контента.
Кроме того, у Amazon S3 или других облачных провайдеров есть свои преимущества. Например, S3 + Amazon CloudFront обеспечит хорошую производительность. CloudFront кэширует ваши файлы на серверах по всему миру, поэтому они будут очень легко / быстро доступны из любого места. НО если мы Для CloudFront за передачу .
Обычно люди хранят двоичные данные, такие как изображения, в файловой системе, а не в базе данных. Они ссылаются на путь файловой системы из базы данных. Получение BLOB (больших двоичных объектов) из базы данных происходит медленнее, чем разрешение веб-серверу обслуживать статические файлы из файловой системы.
Я бы использовал что-то вроде Amazon S3.
Но если выбор стоит между файловой системой и базой данных, я бы выбрал файловую систему, потому что это быстрее загружать образы из файловой системы, чем из базы данных.
Единственная причина, по которой я бы поместил фотографии как большие двоичные объекты в базу данных, была бы в том, что у меня был кластер серверов, и я использовал репликацию базы данных для автоматического копирования фотографий на каждую машину в кластере.
Жизнь будет намного проще, если вы просто сохраните фотографии в виде файлов и сохраните имена файлов фотографий в базе данных. Если вам нужно создать уникальные имена файлов для фотографий, вы можете использовать целое число первичного ключа из базы данных как часть имени файла. Но вы также можете просто использовать хэш самой фотографии, как предложил Джон Милликен. Это просто, а чем проще, тем лучше.
Некоторые люди отмечают, что проще управлять, если в базе данных есть все, включая создание резервных копий и сохранение ссылочной целостности.
Если вы сохраните его в базе данных, база данных будет быстро расти и ее будет много, намного больше. Получить изображение из базы данных для отображения на ощупь сложнее, чем получить его из файловой системы. С другой стороны, вам лучше убедиться, что имена файлов и пути не рассинхронизируются с тем, что хранится в db. Раньше я предпочитал хранить на диске вместо db. Мне стало проще перемещать базу данных в разные ящики. Получилось хорошо.
У нас было аналогичное решение для проекта, над которым я работаю. Неоспоримая особенность заклинивания содержимого (изображений и других объектов типа BLOB) в БД заключается в том, что вероятность того, что кто-то удалит / изменит что-то (намеренно или непреднамеренно), меньше. Но это не тот выбор, который мы сделали. Вместо этого у нас есть информация о пути, хранящаяся в БД, и мы используем ее для ссылки на данные через UNC-путь. Пути к данным хранятся в двух частях - части, которая ссылается на расположение данных относительно того, на каком компьютере они находятся, и части, которая указывает, на каком компьютере находится эта группа данных. Когда нам нужно переместить данные, мы можем обновить соответствующую информацию о пути.
Конечно, быстро получить данные, не вынимая из БД. В конечном итоге это был главный решающий фактор.
Это упрощает жизнь, когда у вас есть база данных BLOB-объектов. Вам следует забыть о кошмаре управления файловой системой.
ИЗМЕНИТЬ
ID
VARBINARY
Исходя из опыта, это эффективный способ управления двоичными файлами. У вас есть одна база данных, в которой есть только двоичные файлы. Как это может быть труднее сделать резервную копию?