Оптимизированное хранилище данных MySQL

Question

Я хотел бы хранить информацию о пользователе в таблице.

Первый пример Поля, напр. «имеет автомобиль», «имеет квартиру», «имеет кошку», «имеет собаку», «имеет ЖК-телевизор», «имеет ноутбук» ...

Значение полей может быть y/n или y/null (null означает пустое значение в таблице).

Поля выше заполнены случайным образом, например. "y", "null", "null", "null", "y", "null" OR "y", "n", "n", "n", "y", "n"

Так что только те поля содержат полезную информацию для меня, которая заполнена «y», потому что, когда я использую запрос, я просто хочу увидеть результат этих полей, которые содержат только «y» значение.

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

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

свойство идентификатор пользователя 1 имеет автомобиль 1 имеет собака 2 имеет ЖК-телевизор 3 имеет плоский 3 имеет ноутбук 3 имеет кошке

Здесь ненужная информация не сохраняются, но DB может иметь более чем 100000 строк.

Мой вопрос - это лучший способ хранения. Для одного пользователя будет использовано свойство 100-120. И будет другая таблица, которая будет подключаться к исходной таблице, которая также будет содержать еще 50 аналогичных свойств (y/null).

Я думаю, что второе решение лучше, но у меня есть сомнения со скоростью. Конечно, первичный ключ будет использоваться, и более важные поля (внешний ключ) будут получены «Уникальными». (Я слышал с уникальными, мы можем получить результаты быстрее).

Что вы думаете о написании выше?

Спасибо за ваши ответы заранее.

С наилучшими пожеланиями & Nice Day, Атти

Answer 1

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

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

Так что, когда вы хотите, чтобы вытащить данные из таблицы, скажем, что пользователь под user_id 5 есть вы будете делать что-то вроде этого

SELECT user_has.user_id, user_has.has_id, has.name 
FROM user_has INNER JOIN has 
ON user_has.has_id = has.has_id 
WHERE user_has.user_id = 5; 

при вставке вы должны вставить только user_id и has_id в user_has таблица, которая будет создавать новую пару ... и т. д.

Answer 2

Что лучше, зависит от того, как данные будут запрашиваться и как ти может измениться в будущем. (TL; DR - первое решение всасывает столько ударов).

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

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

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