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

Question

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

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

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

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

Answer 1

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

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

"колледжи, в которых я учился"

"Кампусы колледжа, которые я посетил"

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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