Как хранить многозначные данные профиля?

0

У меня много полей, которые многозначны и не уверены, как их хранить? если я делаю 3NF, тогда есть много таблиц. Например: Гражданство.

У человека может быть одно или двойное гражданство. если это двойное, это означает, что это число от 1 до многих. Поэтому я создаю таблицу пользователя и таблицу user_nationality. (уже существует таблица поиска национальности). или я мог бы поместить обе национальности в один ряд, например "американский, немецкий", а затем неэтериализовать его во время выполнения. Но тогда я не знаю, могу ли я искать это? как если бы я искал только немецких людей, он будет отображаться?

Это пример, у меня есть более 30 полей, которые многозначны, поэтому я предполагаю, что я не буду создавать 61 таблицу для этого? 1 таблица пользователя, 30 таблиц поиска для хранения каждого многозначного поиска элементов и 30 таблиц для хранения значений user_ для многозначных элементов?

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

Теги:
database
schema
social-networking

5 ответов

0

Вы также можете посмотреть ORM, который автоматически преобразует ваши объекты в базу данных.
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP

0

Это пример, у меня более 30 поля, которые многозначны, поэтому я предположим, что я не буду создавать 61 таблицы для этого?

Вы правы, что 61 - максимальное количество таблиц, но на самом деле это, скорее всего, будет меньше, возьмите свой собственный пример:

", которые я изучил при"

"студенческие городки колледжа, которые я посетил"

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

Я бы сказал, не бойтесь использовать множество таблиц, если набор данных, который вы моделируете, большой - просто убедитесь, что вы постоянно обновляете ERD, чтобы не потеряться! Кроме того, не слишком зацикливайтесь на парадигме "link table" - "таблицы ссылок" могут быть "сущностями" в их собственных правах, например, вы могли бы подумать о том, что "колледжи, которые я изучил на странице ссылок", как вместо таблицы "коллажирование" укажите свой первичный ключ и сохраните каждый раз, когда вы платите комиссионные за курс в виде строк в (связанных) "коллажных зачислениях".

  • 0
    Под таблицами ссылок вы имеете в виду таблицы поиска?
  • 0
    Нет, я имею в виду таблицу с 2 внешними ключами, то есть "регистрация коллажей" связывает "людей" с "коллажами"
0

Простым решением является прекращение использования таблицы SQL. Это то, чем созрел NoSQL. Проверьте CouchDB или Mongo. Там каждое значение может храниться как полная структура, поэтому вся эта проблема может быть сведена к одной (не реально) таблице.

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

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

Если ваша таблица пользователя имеет множество связанных атрибутов, то одна из возможностей - создать одну таблицу атрибутов с такими строками, как (user_id, attribute_name, attribute_value). Вы можете хранить все свои атрибуты в одной таблице. Вы можете использовать эту таблицу для извлечения атрибутов для данных пользователей, а также поиска по именам и значениям атрибутов.

  • 0
    Мне нужно будет смоделировать это и посмотреть, работает ли это.
0

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню