Структура каталогов для хранения изображений ASP.NET - Нужны советы - PullRequest
1 голос
/ 16 ноября 2010

Я работаю над приложением, которое будет хранить около 50 000 изображений за первый год и еще 75 000 за второй.Изображения могут поступать из галерей, изображений новостей, изображений статей и изображений профилей.Поэтому я хочу дать каждому изображению GUID и сохранить GUID в базе данных.

Что касается структуры каталогов, я думал о чем-то вроде этого:

~/Upload/Images/F2/50/F2504E0-4F89-11D3-9A0C-0305E82C3301.jpg

Так что я используюпервые 4 символа GUID в качестве моей структуры каталогов для более равномерного распределения изображений между каталогами.

Теперь у меня есть несколько вопросов об этом подходе:

  • Считается ли хорошей практикой хранить все различные виды изображений вместе, а не использовать ~/Images/Upload/Profiles, ~/Images/Upload/Articles и т. Д.
  • Я также храню миниатюры, и они имеют другой GUID, очевидно, поэтому большие пальцы не будут находиться в той же папке, что и оригинал, и почему-то это не дает мне хорошего ощущения, но я думаю, это не должно иметь значения, но.
  • То же самое относится и к галереям, я привык хранить галереи в таких папках, как ~/Images/Upload/Galleries/12, и теперь все изображения из галереи будут разбросаны по разным подпапкам, это большой удар по производительности?
  • У вас, ребята, есть какие-то другие идеи относительно структуры каталогов?

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

Пожалуйста, дайте мне свое мнение по этому поводу большое спасибо.

С уважением, Марk

Редактировать :
Забыл упомянуть, изображения также будут удаляться довольно часто

Ответы [ 3 ]

0 голосов
/ 16 ноября 2010

Я бы разработал свою модель данных на основе хранения всех этих изображений в БД.Забудьте возиться с каталогом.Затем просто создайте эффективные HttpHandlers для потоковой передачи изображений обратно.

Если вы собираетесь хранить пути в БД и изображения в каталоге, я бы постарался сохранить пути как можно более простыми.Наилучший баланс производительности может зависеть от размера изображений;Вы можете посмотреть на FileStream класс.

Некоторые ресурсы:

http://www.homeoftester.com/viewtopic.php?t=2648&sid=2f86787a27a5690db35df9b61f9e8247

Хранение изображений в БД - даНет?

http://www.sqlskills.com/BLOGS/PAUL/post/High-performance-FILESTREAM-tips-and-tricks.aspx

0 голосов
/ 16 ноября 2010

Я думаю, вы могли бы также использовать функцию потокового файла sql server 2008 для хранения изображений и лучшего управления ими.

Потому что в функции потокового файла вы можете физически хранить изображения и управлять ими через SQL Server.Таким образом, вы можете воспользоваться обоими преимуществами.

Вот хорошие ссылки для этого http://www.simple -talk.com / sql / learn-sql-server / введение-в-sql-server-filestream /

http://weblogs.asp.net/aghausman/archive/2009/03/16/saving-and-retrieving-file-using-filestream-sql-server-2008.aspx

0 голосов
/ 16 ноября 2010

Мой единственный комментарий - предложить вам не делать каталоги, как вы планируете;Вместо этого посмотрите, можете ли вы придать какую-то логическую организацию структуре папок.Я был бы готов поспорить, что вы могли бы в конечном итоге вытащить одну или две волоски с этой, по сути случайной, структурой каталогов.

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

Одна возможность;пусть они будут основаны на времени ... ~/Images/Upload/2010/11/15 например.Идите дальше, если это кажется хорошим, или не так далеко, если вы предпочитаете.(например, перейдите только к месяцу или укажите номер недели вместо дня).Я бы также порекомендовал сохранить ведущие 0 в такой схеме, чтобы упростить сортировку.

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

...