Некорректно работает запрос в БД

[Yan]

Повторяю вопрос - нафига две таблицы?…

Вы имеете ввиду, чтобы эти 2 таблицы поместить в 1? Тогда будет следующее: в таблице будет несколько строк из того самого массива, у каждой из этих строк будет поле с id юзера, но тогда это затруднит определение того, сколько раз один юзер проголосовал, т.к. количество строк, полученных от юзера (из массива) я заранее не знаю, оно разное при каждом голосовании. Проще просто проверить есть id или нет, для этого и делаю 2 таблицы. В таблице, в которую я раскладываю данные из массива, я эти значения прибавляю, а не добавляю ниже дополнительные строки, полученные от очередного юзера.
Поэтому 2 таблицы. Или в вашем представлении другая структура таблицы?

 

[AnrDaemon]

Не будет. И не затруднит. Кончаем тупить.

CREATE TABLE `vote_results` (
  `vote_id` INTEGER UNSIGNED NOT NULL REFERENCES `votes` (`vote_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  `user_id` INTEGER UNSIGNED NOT NULL REFERENCES `users` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  `user_choice` TEXT NOT NULL,
  UNIQUE KEY `vote` (`vote_id`, `user_id`)
)

В user_choice сваливаешь прямо JSON с выбором пользователя, как есть. Всё!…
Не надо ничего проверять. Не надо ничего выдумывать.
Если юзер попытается проголосовать повторно в том же голосовании, ключ ему этого не даст сделать!

 

[Yan]

Не будет. И не затруднит. Кончаем тупить.

CREATE TABLE `vote_results` (
  `vote_id` INTEGER UNSIGNED NOT NULL REFERENCES `votes` (`vote_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  `user_id` INTEGER UNSIGNED NOT NULL REFERENCES `users` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  `user_choice` TEXT NOT NULL,
  UNIQUE KEY `vote` (`vote_id`, `user_id`)
)

В user_choice сваливаешь прямо JSON с выбором пользователя, как есть. Всё!…
Не надо ничего проверять. Не надо ничего выдумывать.
Если юзер попытается проголосовать повторно в том же голосовании, ключ ему этого не даст сделать!

Спасибо большое, буду разбираться с этим, половина для меня незнакома)

 

[WMix]

меня медленно начинает пугать эта мода,

В user_choice сваливаешь прямо JSON

вижу скопище разнородных обьектов в поле и кучу стратегий по считыванию

 

[Yan]

меня медленно начинает пугать эта мода,

вижу скопище разнородных обьектов в поле и кучу стратегий по считыванию

А по вашему мнению как это лучше организовать и почему мой короткий код работает не так, как задумывался?

 

[AnrDaemon]

меня медленно начинает пугать эта мода,

вижу скопище разнородных обьектов в поле и кучу стратегий по считыванию

Ну, у нас тут однородный объект - список выбранных пунктов в голосовании.
Не вижу большой беды.

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

 

[grigori]

мы как-то несколько месяцев потратили на переписывание json-полей, чтобы можно было создавать новую логику для существующей пользовательской базы

 

[AnrDaemon]

Сейчас вроде уже есть поддержка JSON в MySQL даже, не?

 

[c0dex]

Сейчас, это с версии 5.7.

 

[AnrDaemon]

Ну, 5,7 GA же ж. Значит, сейчас.

 

[Фанат]

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

 

[c0dex]

@AnrDaemon, это ты хостерам про GA скажи)

 

[AnrDaemon]

@Фанат, согласен.
@c0dex, у нас эпоха шаредов возвращается?

 

[c0dex]

@AnrDaemon, у нас нет, а у хомякоф она и не проходила =(