Хитрый дизайн базы данных - PullRequest
2 голосов
/ 23 апреля 2011

Мне нужно спроектировать базу данных для хранения пользовательских значений: для каждого пользователя есть определенный набор столбцов.

Например, Джон хочет сохранить значения в таблице с 2 столбцами: имя, возраст.

И Пол хочет сохранить значения в таблице из 3 столбцов: фрукты, цвет, вес.

На данный момент у меня есть 2 варианта.

Опция1 - Сохранить данные в виде текстовых значений

У меня будет первая таблица «профили» с предпочтениями пользователя:

+----+---------+--------+-------------+
| id | user_id | label  | type        |
+----+---------+--------+-------------+
|  1 |       1 | name   | VARCHAR(50) |
|  2 |       1 | age    | INT         |
|  3 |       2 | fruit  | VARCHAR(50) |
|  4 |       2 | color  | VARCHAR(50) |
|  5 |       2 | weight | DOUBLE      |
+----+---------+--------+-------------+

А затем сохраните данные в виде текста в другой таблице:

+----+------------+--------+
| id | id_profile | value  |
+----+------------+--------+
|  1 |          1 | Aron   |
|  2 |          2 | 17     |
|  3 |          1 | Vince  |
|  4 |          2 | 27     |
|  5 |          1 | Elena  |
|  6 |          2 | 78     |
|  7 |          3 | Banana |
|  8 |          4 | Yellow |
|  9 |          5 | 124.8  |
+----+------------+--------+

После этого я программно создаю и заполняю чистую таблицу.

Вариант 2 - один столбец на тип

На этомОпция, у меня будет первая таблица 'profile2', например:

+----+---------+--------+------+
| id | user_id | label  | type |
+----+---------+--------+------+
|  1 |       1 | name   |    3 |
|  2 |       1 | age    |    1 |
|  3 |       2 | fruit  |    3 |
|  4 |       2 | color  |    3 |
|  5 |       2 | weight |    2 |
+----+---------+--------+------+

с типом, соответствующим набору типа: 1 = INT, 2 = DOUBLE, 3 = VARCHAR (50)

И таблица данных вот так:

+----+-------------+-----------+--------------+---------------+
| id | id_profile2 | int_value | double_value | varchar_value |
+----+-------------+-----------+--------------+---------------+
|  1 |           1 |      NULL |         NULL | Aron          |
|  2 |           2 |        17 |         NULL | NULL          |
|  3 |           1 |      NULL |         NULL | Vince         |
|  4 |           2 |        27 |         NULL | NULL          |
|  5 |           1 |      NULL |         NULL | Elena         |
|  6 |           2 |        78 |         NULL | NULL          |
|  7 |           3 |      NULL |         NULL | Banana        |
|  8 |           4 |      NULL |         NULL | Yellow        |
|  9 |           5 |      NULL |        124.8 | NULL          |
+----+-------------+-----------+--------------+---------------+

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

Вопросы

Кто-нибудь когда-нибудь сталкивался с такой ситуацией?

Что вы думаете о моих 2 вариантах?

Есть ли лучшее решение, менее хитрое?

Tx много!

Edit Снова привет,

В моей модели была ошибка: невозможно получить «строку» информации;то есть информация в таблице «значения» не является сортируемой.

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

ТогдаЯ закончил с этой моделью: Таблица меток 'метки':

+----+------------+------+----------+
| id | profile_id | name | datatype |
+----+------------+------+----------+
|  1 |          1 | 1    | Nom      |
|  2 |          1 | 1    | Age      |
|  3 |          2 | 2    | Fruit    |
|  4 |          2 | 2    | Couleur  |
|  5 |          2 | 2    | Poids    |
+----+------------+------+----------+

Затем очень простой тальб 'узлы', просто чтобы отслеживать линии информации:

+----+------------+
| id | profile_id |
+----+------------+
|  1 |          1 |
|  2 |          1 |
|  3 |          2 |
|  4 |          2 |
+----+------------+

инабор таблиц, соответствующих разным типам данных:

+----+---------+----------+--------+
| id | node_id | label_id | value  |
+----+---------+----------+--------+
|  1 |       1 |        1 | John   |
|  2 |       2 |        1 | Doe    |
|  3 |       3 |        3 | Orange |
|  4 |       3 |        4 | Orange |
|  5 |       4 |        3 | Banane |
|  6 |       4 |        4 | Jaune  |
+----+---------+----------+--------+

С этой моделью запросы в порядке.Ввод данных немного сложен, но я справлюсь с чистым кодом.

Cheers

Ответы [ 3 ]

2 голосов
/ 23 апреля 2011

Вариант 3: создать две разные таблицы.

Один стол явно для людей. Другой, очевидно, для фруктов. Они должны быть в разных таблицах.

2 голосов
/ 23 апреля 2011

Взгляните на модели данных EAV .

0 голосов
/ 23 апреля 2011

Почему бы просто не иметь пользовательскую таблицу с именем и идентификатором, таблицу userValues, которая имеет пары ключ-значение?у Джона могут быть ключ "фрукты" и значение "манго", а другой ключ "шины" и значение "гудиер". Боб может иметь ключ "монета" и значение "пенни", ключ "возраст" и значение "42".может иметь любое значение, которое им нравится, и вы обладаете максимальной гибкостью. Скорость не будет большой, и вам придется приводить строку к значениям, но это всегда компромисс.

Приветствия, Даниэль

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...