#mysql #database
#mysql #База данных
Вопрос:
Я хочу создать демонстрационное приложение, которое может спросить пользователя, следовал ли он правильным методам создания элемента.
Я создал «контрольный список», который пользователь должен заполнять по мере создания элемента. Например, некоторые из вопросов могут быть:
- Вы получили правильные части?
- Детали в хорошем состоянии?
- Вы создаете стул?
- У вас есть правильные спецификации для кресла?
- …
- …
…
И так далее…
Итак, на эти вопросы есть только ответы «да» / «нет». Мой план состоял в том, чтобы создать таблицу и вызывать каждый столбец по номеру вопросов. Итак, столбец 1 будет называться «1», и это первый вопрос. Столбец 2 будет называться «2», и это второй вопрос и так далее.
Таким образом, эта таблица будет называться Chair inspection. Затем у меня есть еще одна таблица, называемая Table inspection, со своим собственным набором контрольных вопросов.
Эти данные собираются с помощью приложения для Android. Разработка приложения завершена. Просто нужен совет по части базы данных.
Является ли это правильным подходом к хранению вводимых пользователем данных?
Комментарии:
1. Нет. Таблица базы данных не является электронной таблицей. Пожалуйста, смотрите о «нормализации»
2. @Strawberry итак, нормализация заключается в «организации столбцов (атрибутов) и таблиц (отношений) базы данных, чтобы гарантировать, что их зависимости должным образом соблюдаются ограничениями целостности базы данных». Моя таблица users ID в качестве первичного ключа, и я добавил столбец user, чтобы я знал, кому принадлежат ответы. Не могли бы вы предложить мне использовать один столбец для ответов «да» / «нет» вместо нескольких столбцов, как я это делал?
3. Что происходит, когда вы хотите добавить седьмой элемент в контрольный список?
4. Это действительно плохое решение. Дополнения к базе данных не должны требовать структурных изменений, и запросы к этому набору данных, вероятно, будут крайне неэффективными. Очевидно, что вы можете делать то, что вам нравится, но если вы собираетесь использовать СУБД, тогда кажется глупым не структурировать вашу схему соответствующим образом. Для обсуждения более высокого уровня о причинах и причинах нормализации, вы могли бы добиться большего успеха на форуме администратора базы данных; во всяком случае, более подробный ответ выше моего уровня оплаты.
5. Я не знаю, почему это помешало бы использованию Excel, но в любом случае… мы отвлеклись
Ответ №1:
Я советую вам иметь три таблицы: одну для вопросов, другую для пользователей, которые будут отвечать на эти вопросы, и последнюю для ответов, затем вы устанавливаете связь между этими тремя таблицами. Это означает, что многие пользователи могут ответить на многие вопросы. Поэтому между пользователями и вопросами будет много-много отношений. Тогда будет взаимосвязь между вопросами и ответами и ответ с пользователями, которые ответили на вопросы.
Я думаю, что таким образом вы сможете избежать избыточности и упростить процесс обновления и извлечения ваших данных.
Ответ №2:
Нормализованная схема может быть следующей (неполной и пока игнорирующей «таблицы») :
inspection
inspection_id* item inspected_by date
inspection_detail
inspection_id* checklist_id* status
* = (component of) PRIMARY KEY