Кроме объединения 20 таблиц какие-либо другие варианты записи / чтения данных?

Question

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

Так что читать данные при вводе пользователем можно, но после этого возникают две проблемы:
1) Запись данных:это отношение M: M, мне понадобятся 20 разных таблиц?
2) Чтение данных во время загрузки профиля: мне нужно объединить все эти 20 таблиц, чтобы получить данные пользователя?

Какие другие опции делаютя должен хранить все эти данные пользователя?Моя единственная забота - производительность, так как это социальный сайт.20 объединений не хорошо.Но я не уверен в других методах.Я использую mysql и php.

Единственный другой вариант, о котором я могу подумать, - это сохранить данные в массиве в БД, хотя я не знаю, насколько хорошо с этим будет работать поиск.

Answer 1

1. Установите ваши любимые базы данных.
2. Создайте пользовательскую таблицу и два или три таблицы избранного пользователя.
3. Напишите небольшую программу для генерации и загрузите миллион случайных пользователей.
4. Напишите небольшую программу для генерации и загрузите 10 миллионов любимых фильмов (или что-то еще) для тех миллионов пользователи.
5. Выполнить несколько запросов.

Если проблема связана со скоростью, опубликуйте схему с тегами «database-design» и «query-оптимизация» и включите ссылку на этот вопрос.

---

Позже. , . Скучно. Так что я сделал тест самостоятельно. У меня нет времени, чтобы сделать 20 объединений, но 5 оставленных объединений в таблице с миллионами пользователей и более 50 миллионов строк в каждой из объединенных таблиц возвращаются за 400 миллисекунд. (PostgreSQL 9.0.2) Вернуться к работе сейчас. , .

---

И еще позже. , . Все еще скучно. Я добавил больше таблиц, больше данных, больше левых внешних объединений. В зависимости от данных для определенного адреса электронной почты, больше объединений может быть еще быстрее. (Вы бы догадались?) Последний тест, который я выполнил, выбрав несколько десятков случайных адресов электронной почты из списка «пользователи»,

           run time (milliseconds)
--
median      40 
maximum    222
minimum      0.4 ("Four tenths of a millisecond", not a typo.)

Если мне все еще будет скучно позже, я собью программу на

• выполнить несколько сотен запросов на основе на случайные адреса электронной почты и
• записать время выполнения (хотя я не уверен, что это возможно)

Answer 2

Один из способов сократить количество объединений - сохранить данные, общие для всех 20 типов, в одной таблице. Отношение этой таблицы к 20 специализированным таблицам соответствует шаблону проектирования gen-spec. Найдите "обобщение реляционного моделирования специализации", чтобы увидеть, как реализовать шаблон gen-spec в таблицах.

Если вы сделаете это, вы будете ссылаться на специализированные таблицы только тогда, когда они вам нужны.

Я не уверен в ваших шаблонах использования в вашем случае, поэтому я не могу сказать, относится ли этот совет к вашей ситуации. Но это стоит посмотреть.

Answer 3

Нужно ли загружать ВСЕ данные при загрузке профиля?Мне кажется, что ваша справочная таблица NAMES представляет собой своего рода доступ к самому профилю, который при активации пользователем выполняет запрос для элементов из этой таблицы, нет?

Я не являюсь опытным веб-программистом, так что я мог бы все это неправильно.Но кажется, что профиль загружается и представляет пользователю, что представляет собой сводный / навигационный интерфейс, верно?С некоторыми кнопками / символами, которыми вы пользуетесь, чтобы перемещаться и / или запрашивать дополнительную информацию

При загрузке профиля появляется информация о профиле верхнего уровня, а также (значительно упрощенно) некоторые кнопки, возможно, под виджетом заголовка «Мое избранное».Могут существовать кнопки для «PLaces», «Food / Drink», «Music» и т. Д. Когда пользователь активирует один из THESE, выполняется запрос к этой конкретной таблице (и любым соответствующим соединениям), чтобы вернуть данные, относящиеся к «Places»например.

Может быть, с Web все по-другому (и я скоро буду изучать), но я пытаюсь запрашивать данные, когда это имеет смысл, и в тот момент, когда пользователь может ожидать короткого времени доступа.Нажатие кнопки обычно является точкой, в которой пользователь будет ожидать небольшую задержку в ответе.

Answer 4

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

Я был бы удивлен, если бы вы не смогли объединить некоторые из них. Я думаю, что многие из атрибутов профиля могут быть представлены в общей структуре, такой как PersonId, TraitType, string1, string2, int1, int2, date1, date2.

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

• Elroy

Answer 5

Вы можете хранить профили пользователей в нереляционном хранилище данных, например MongoDB .

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

Answer 6

20 объединений не хорошо

Кто сказал?Я не буду беспокоиться о количестве объединений в ваших запросах, если вы не увидите, что это действительно становится проблемой.Реляционные базы данных предназначены для обхода, ну, в общем, связи таблиц друг с другом.

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