Для такой задачи делать JOIN, еще и LEFT JOIN - фу-фу-фу. Базу, вижу, Вам совсем не жалко!
Чем подряд 2 запроса не угодили? Сначала выбираем нужные статьи, собираем с них айдишники юзеров и выбираем потом по этим айдишникам нужных юзеров (а если у Ваш юзеры кешируются, то можно и из кеша дернуть). Для конечного юзера разница во времени отклика будет не ощутимой, а база под нагрузкой спасибо скажет за то, что не заставляете ее делать лишние накладные расходы на временные таблицы, а данные сразу по индексам дергаете простыми запросами.
И на Ваш sqlx такое дело ляжет так, как Вы хотели. Сначала заполняете map'у или slice Article'ов, потом вытаскиваете User'ов и раскидываете указатели на конкретного User'а конкретному Article'у.
@Boniface: раз уж Вы копнули и разобрались, очень попрошу Вас написать тогда более-менее нормальный ответ на Ваш вопрос и пометить его как решение. И желательно туда впихнуть ссылки на тот же SO или ещё полезные. У Вас много времени не займет, а многим людям время сэкономит.
@eliseevmax, ну...Martini вдохновлен express/sinatra, более монструозный Revel вдохновлен Play framework'ом, BeeGo пишут, что тоже вдохновлен sinatra/tornado, но в нем из коробки больше есть всякого интересного (например, ORM).
Выбирайте то, что ближе Вам по духу.
Лично я бы выбрал BeeGo, потому что Revel - слишком монструозно для меня, а Martini - это больше даже не фреймворк, а такая себе концепт-рама (просто фрейм =)), на которую уже можно навешивать что тебе хочется, но в принципе что мне хочется я могу и навешивать на net/http, грубо говоря. BeeGo же дает больше того, что мы привыкли видеть в традиционных фреймворках и за что их любим - не только раму, но и кучу инструмента из коробки вроде генерации форм/встроенной XSRF защиты/ORM/%другая приятная фича%. Ведь задача стоит сравнить именно с фреймворком.
@maxloyko, д, хорошо, что упомянули, пример может быть на 4 строки короче, если пост-инкремент вписать прямо в индекс...аля $first[$f++]
Я просто привык по дефолту юзать пре-инкремент, и чего-то сразу не подумал.
@cnaize, если честно - совершенно не понятно о чем вопрос. Начали об архитектурном решении, закончили о том с каким приоритетом вычислять опции? При этом совершенно непонятно каким боком связаны группы пользователей и эти самые опции. И ещё больше непонятно каким образом этот вопрос относится к языку программирования Go, если о нем ни слова, а задача скорее всего - проектирование таблиц в БД?
Сформулируйте, пожалуйста, вопрос однозначно и корректно, тогда Вам смогут помочь. А шаманов и оракулов ищите не на этом форуме.
@DubecZ не понимаю зачем тут единицу параметризовать (email'ы то, по идее, и так уникальны для пользователей), что мешает написать "LIMIT 1" конкретно в данном случае?
А вообще, выше @asdz уже дал толковую ссылку. Если с английским проблема, то там говорится, что параметры для LIMIT нужно явно привести к типу int ((int) $lim, или intval($lim)) и байндить отдельно с указанием что конкретно это конкретно числовой параметр PDO::PARAM_INT.
А вообще, погуглите, должны уже быть готовые решения под это дело в виде всяких CRM'ок, которые можно доподпилить под себя. Времени займет меньше, чем писать с нуля.
Что лучше использовать - зависит от того что Вы уже знаете (насколько я понимаю, задачу лучше решить быстро). Если не знаете ничего, то быстрее всего будет усвоить PHP и наваять на каком-нибудь фреймворке, они достаточно дружелюбные....Laravel хвалят в последнее время, можно что-то попроще аля Silex (или Sinatra под Ruby). Если знакомы с C#, то быстрее будет, разумеется, на нем, фреймворки тоже есть, тот же MVC.
Если не охота сильно заморачиваться с серверной частью, то можно её оформить в виде примитивного HTTP JSON API, а всю остальную прелесть перенести на JS + HTML (то, что называют одностраничным приложением), но имхо, это немного overkill для этой задачи =)
@Cyapa вопрос невозможности смены цены во время обработки запроса, имхо, нужно решать на уровне приложения, а не БД. Поле со статусом то есть, что мешает атомарно проверять этот статус при попытке сменить цену? Подобным образом, уверен, можно решить и другие подобные ситуации, немного подумав. Тут уж извините, без подробностей не скажу точно.
На вкус и цвет... =) Если не эстетично - нужно переделывать схему грамотнее тогда (sql way): бьем таблицу на несколько со связями 1 к 1, соответственно те поля что есть не у всех записей - выносим в эти таблицы.
Также, чтобы не блокировать все дело тяжелыми транзакциями, можно предусмотреть дополнительное состояние таска "оценивается". То есть исполнитель одним атомарным UPDATE SET status='оценивается' захватывает таск, и все, больше ничего не блокируется, дальше, спокойно себе проверяются все условия по таску (тут можно и кеши подрубить чтобы нагрузку снять еще), если результат оценки положительный, выставляем статус "на обработке" и отрабатываем, если нет, возвращаем таск в свободное плавание и захватываем/оцениваем следующий свободный.
@doublench21 ага, теперь при открытии Remote Host вкладки у Вас директория деплоя будет выделяться зеленым фоном (в Вашем случае должны выделяться все папки, так как деплоите в корень). Чтобы залить на сервер, нужно задеплоить, да, но термин "сохранить" мне не нравится в данной ситуации, потому что хранить изменения в файлах нужно в системе контроля версий, а на сервер деплоить для разработки/тестов/etc. .
Насколько я понимаю, Вы имеете в виду num := len(results), ибо num до этого не инициализировано. Если функция ожидает как результат множественную выборку м указанием кол-ва выбранных записей, и Вы её используете чтобы заполнять slice'ы различных типов, почему бы для results не использовать []interface{} вместо просто interface{} ?
Чем подряд 2 запроса не угодили? Сначала выбираем нужные статьи, собираем с них айдишники юзеров и выбираем потом по этим айдишникам нужных юзеров (а если у Ваш юзеры кешируются, то можно и из кеша дернуть). Для конечного юзера разница во времени отклика будет не ощутимой, а база под нагрузкой спасибо скажет за то, что не заставляете ее делать лишние накладные расходы на временные таблицы, а данные сразу по индексам дергаете простыми запросами.
И на Ваш sqlx такое дело ляжет так, как Вы хотели. Сначала заполняете map'у или slice Article'ов, потом вытаскиваете User'ов и раскидываете указатели на конкретного User'а конкретному Article'у.