Эффективность SQL Больше таблиц или более строк

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

Это более эффективно, чтобы иметь 100 таблиц (с user_id в качестве имени таблицы) для каждого пользователя с соответствующими 10000 фотографий ИЛИ Одна таблица, состоящая из всех 1,000,000 фотографий ИЛИ там просто нет разницы в какой-либо способ, связанный с производительностью базы данных?

В обоих случаях число будет продолжать расти (то есть больше пользователей или больше фотографий)

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

источник

2015-03-11 starky

Это для MySQL или SQL Server? Вы храните изображения/двоичные данные в базе данных или только информацию о пользователе? В любом случае, вы почти наверняка не хотите иметь уникальную таблицу для каждого пользователя. –

Как правило, ваша схема должна быть статичной (при отсутствии изменений в коде приложения, требующем изменения схемы). Таким образом, один стол с фотографиями 1 м - лучший способ - правильно проиндексирован, он будет работать лучше, чем отдельные таблицы. – eggyal

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

Возможно, вам понадобится всего две таблицы для отношений между многими. Таблица с идентификаторами пользователя (вероятно, другая пользовательская информация), таблица с фотографиями и идентификаторами пользователей (внешняя привязка к таблице пользователей).

Что-то вроде этого: пользовательской таблицы

UserID Name DateJoined etc. 
1  Dan 2015-01-01 ... 
2  Jim 2015-02-01 ...

фото таблица (вы можете сохранить реальное фото в таблице, если вы собираетесь сделать это использовать FILESTREAM на SQL Server, и я не думаю, Я бы рекомендовал его на MySQL)

PhotoID UserID PhotoPath  PhotoTitle 
1  1  '/img/asdf.jpg' 'My favorite' 
2  2  '/img/asdf2.jpg' 'First!' 
3  1  '/img/asdf3.gif' 'Animated favorite'

Ваш ImagePath либо должны быть однозначно порождаемыми (использовать GUID/UUID для имени файла, сохранить все фото пользователя в определенной директории, или что-то вдоль этих линий).

Если вы действительно хотите хранить фотографии и связывать их с пользователем, вы можете рассмотреть базу данных NoSQL/Document.

источник

2015-03-11 03:50:03

Зачем ФП в этом случае нужна третья (ассоциативная) таблица? Все фотографии принадлежат пользователю * single *, поэтому для столбца «владелец» во второй таблице должно быть достаточно отношения 1: много. Таблицы ассоциации нужны только для многих: многих отношений. – eggyal

Ahh, я пропустил ту часть, где каждый пользователь владеет собственными фотографиями. Ты прав. Я поправлю этот пост. –

Если единственная динамическая информация, которую вы хотите сохранить, - это заголовок, который я не вижу, почему вы хотите пройти через накладные расходы, имея такую огромную таблицу. Сохранение данных в файловой системе (с использованием идентификатора пользователя в качестве имени каталога и закодированного заголовка в качестве имени файла) выполнило бы эту работу. См. Мой комментарий к вопросу. – phpPhil

Эффективность SQL Больше таблиц или более строк

ответ

Смежные вопросы