единственная причина иметь разные таблицы заключается в том, что вы можете иметь FKs. Но это veruy, очень важно для целостности данных.

одна из причин, чтобы иметь одну таблицу со всеми фотографиями было бы, если бы вы хотели сделать один запрос против всех фотографиях.

другой причиной может быть то, что это упрощает написание вашего приложения (i.e потому что вам не нужно менять код, который работает в одной таблице фотографий)

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

когда у меня есть какая-то сущность, которая повторяется в нескольких контекстах, например почтовый адрес, я часто собираю их все в одной таблице. Это обычно упрощает проверку (например, почтовые индексы), управление дубликатами... .

при необходимости у меня будет таблица перекрестных ссылок. Например, номера телефонов могут находиться в одной таблице вместе с примечанием ("home", "mobile",...). Таблица перекрестных ссылок между поставщиками и телефонными номерами может соответствовать одному человеку с as много телефонных номеров по мере необходимости. Он также предоставляет возможность добавить ранг, чтобы они могли указать свой предпочтительный номер телефона. В некоторых случаях вы можете запросить у пользователя обновление информации о связанных изменениях, например, при обновлении номера 800 для компании, должны ли обновляться какие-либо другие ссылки на него?

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

BLOBs-это другое обсуждение. Фотографии, PDF-документы и другие громоздкие двоичные файлы имеют проблемы с размером базы данных, соглашениями об именах, резервным копированием/восстановлением ... . Они несколько различаются в зависимости от используемой конкретной версии SQL Server.

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

1. попытайтесь распространить изображения по нескольким таблицам, особенно если вы собираетесь отображать миниатюры изображений, которые будут значительно быстрее извлекаться, чем полноразмерные изображения.
2. таблицы, изображения должны быть независимый от связанных данных, например. alt текст, имя, описание или метки. Единственное, что я бы с изображением-это первичный ключ и установлен ЭГ. jpg, jpeg, png, gif, bmp и т. д.
3. избегайте использования функции LINQ where. Вместо этого структурируйте sql-запрос самостоятельно, поскольку по причинам, которые я еще не выяснил, функция where намного медленнее, чем написание sql-запроса, который делает то же самое. Не во всех случаях, но если вы используете linq и во время отладки, вы обнаружите, что где метод занимает много времени, чтобы закончить, то определенно напишите свой собственный SQL-запрос.
4. попробуйте обеспечить, чтобы загруженные фотографии были обрезаны до фиксированного соотношения или даже уменьшены до стандартного размера. Это может быть не нужно в зависимости от ваших целей, но по моему опыту, это экономит много боли, когда дело доходит до отображения collectionOfImage в сетке или списке.

FileStream в порядке, как обсуждалось выше. Но это сложно. Знаешь, что лучше хранить в файле? Файловая система. Вот что он делает. Вам просто нужно настроить общий ресурс, на который могут писать все ваши веб-серверы, и ваш процесс сохранения: 1) создать идентификатор изображения, 2) сохранить файл, используя его в качестве имени, 3) вставить строку, указывающую сетевой путь к файлу или url-адрес файла. Затем ваша таблица БД остается маленькой и быстрой, и ваш клиент может вытащить файл из файловой системы. Это дешевле, быстрее, надежнее настроить терабайтный файловый сервер с RAID на SSDs для хранения ваших файлов и просто сохранить путь доступа на сервере баз данных. BLOBs имеют странные эффекты в sql server, например, не отказываются от своего пространства после удаления и много других проблем (не удается перестроить кластеризованный индекс в интернете и т. д.).