Работа с MySQL Vertical Designed таблицей

Question

У меня есть html-форма (каждая форма имеет свою страницу в соответствии с датой), с пятью текстовыми вводами, называемыми date, inp1, inp2, inp3 и inp4.

Например, у меня есть таблица базы данных со структурой, подобной этой: id | parent | name | value. В этом случае я хочу сохранить свои данные и добавить их к дате по родителям, например:

id | parent | name | value
1  | 0      | date | 20.07.2011
2  | 1      | inp1 | value-from-inp1
3  | 1      | inp2 | value-from-inp2
4  | 0      | date | 21.07.2011
5  | 4      | inp2 | value-from-inp2
6  | 1      | inp3 | value-from-inp3
7  | 4      | inp1 | value-from-inp1

и так далее ...

Но проблема начинается здесь. Я хочу создать опцию, чтобы вы могли обновить эти значения для ранее добавленных. Но ВОПРОСЫ, как проверить, если

1. У меня уже есть что-нибудь назначенное на эту дату?
2. Если назначено, как определить и использовать для этого MySQL Update
3. Если не назначено, как определить и использовать для этого MySQL Insert Into

Мое глупое и на 50% более неэффективное решение для загрузки страницы для этой проблемы звучит так (не беспокойтесь о безопасности, это просто макет):

if($_POST['submit']){
$inp1_data = $db->get_row("SELECT name FROM table WHERE parent = ".$parent_id." and name='inp1'");
if($inp1_data){$db->update($query)}else{$db->insert($query)}

// ... and so on, four copies of same code, just replacing "inp1" to "inp2", "inp3"...
}

Да, я знаю, что это бесполезный скрипт, на случай, если я добавлю еще один или сотни inpNUMBER, это будет тестовый сайт, 100% гарантированное время ожидания, неработающий скрипт.

Answer 1

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

Рассмотрим этот альтернативный дизайн, который предполагает, что данное поле не может быть повторено для данной отправки:

Таблица подачи

submission_id | date
1             | 20.07.2011
2             | 21.07.2011

таблица ответов

submission_id | field_name | field_value
1             | inp1       | value-from-inp1
1             | inp2       | value-from-inp2
2             | inp2       | value-from-inp2
2             | inp4       | value-from-inp4
1             | inp3       | value-from-inp3

Обратите внимание, что предложение Рандольфа Ринкона-Фадула о том, чтобы разделять типы данных по полям, является хорошим, но я не сделал этого здесь, чтобы упростить задачу. Теперь вы можете узнать, есть ли у вас ответ на конкретную дату, присоединившись к таблицам.

Answer 2

RobertR Я согласен с Керреком, это ОЧЕНЬ ПЛОХОЙ человек идеи!Вы должны нормализовать свои данные.Эта структура не дает никаких реальных преимуществ БД, и попытка анализа и обслуживания данных на основе вашей «схемы» будет болезненной.

Theres - это всегда форма.Если вам нужно сохранить определенные пользователем данные, используйте общие столбцы БД, такие как [FIELD_NAME] [FIELD_TEXT_VALUE] и [FIELD_NAME] [FIELD_DATE_VALUE], где все они атомарные.