& ldquo; [, & hellip; args] & rdquo; в Socket.io docs [duplicate]

Я бы просто добавил group_id к GROUP BY.

Когда SELECT столбца, который не является частью GROUP BY, может быть несколько значений для этого столбца внутри групп, но в результатах будет только одно место для одного значения. Таким образом, для базы данных обычно должно быть сказано точно, как сделать эти несколько значений одним значением. Обычно это выполняется с помощью агрегатной функции, такой как COUNT(), SUM(), MAX() и т. Д. Я обычно говорю , потому что большинство других популярных систем баз данных настаивают на этом. Однако в MySQL до версии 5.7 поведение по умолчанию было более прощающим, потому что оно не будет жаловаться, а затем произвольно выбирает любое значение ! Он также имеет функцию ANY_VALUE(), которая может быть использована в качестве другого решения для этого вопроса, если вам действительно необходимо такое же поведение, как и раньше. Эта гибкость стоит дорого, потому что она недетерминирована, поэтому я бы не рекомендовал ее, если у вас нет веских оснований для ее использования. MySQL теперь по умолчанию устанавливает параметр only_full_group_by по уважительным причинам, поэтому лучше всего привыкнуть к нему и выполнить ваши запросы.

Итак, почему мой простой ответ выше? Я сделал несколько предположений:

1) group_id уникален. Кажется разумным, это «идентификатор» в конце концов.

2) group_name также уникален. Это может быть не такое разумное предположение. Если это не так, и у вас есть дубликат group_names, и затем следуйте моему совету, чтобы добавить group_id к GROUP BY, вы можете обнаружить, что теперь у вас больше результатов, чем раньше, потому что группы с тем же именем будут теперь имеют отдельные строки в результатах. Для меня это было бы лучше, чем скрытие этих дублирующих групп, потому что база данных спокойно выбрала значение произвольно!

Также неплохо квалифицировать все столбцы с их именем таблицы или псевдонимами, когда задействовано более одной таблицы ...

SELECT 
  g.group_id AS 'value', 
  g.group_name AS 'text' 
FROM mod_users_groups g
LEFT JOIN mod_users_data d ON g.group_id = d.group_id 
WHERE g.active = 1 
  AND g.department_id = 1 
  AND g.manage_work_orders = 1 
  AND g.group_name != 'root' 
  AND g.group_name != 'superuser' 
GROUP BY 
  g.group_name, 
  g.group_id 
HAVING COUNT(d.user_id) > 0 
ORDER BY g.group_name
75
задан Peter O. 17 January 2013 в 20:24
поделиться

4 ответа

Итак, почему API-документация написана таким образом, чтобы путать многолетних новичков / хакеров / DIY, таких как я?

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

Как правило, тип человека, который работает с API, будет иметь некоторый опыт в разработке или, по крайней мере, «полномочным пользователем». Эти типы пользователей используются для таких соглашений синтаксиса, и для документа API имеет смысл больше, чем пытаться создать новые.

Есть ли какой-то таинственный документ где-то, что говорит людям, как читать документацию по API ?

На самом деле не существует стандарта, или RFC, supersekretsyntaxdoc, лежащего где угодно, однако существует файл с 30-летним файлом формата UNIX man-страницы , который широко используется [30].

Некоторые примеры этого (и ответа на ваш вопрос) были бы следующими:

Подчеркнутые слова считаются литералами и набираются так, как они появляются.

Квадратные скобки ([]) вокруг аргумента указывают, что аргумент не является обязательным.

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

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

A Почти вся документация, связанная с программированием, использует этот тип соглашения о синтаксисе, из Python , man pages , javascript libs ( Highcharts ) и т. д.


Нарушение вашего примера из Adobe API

fillPath
([fillColor]
[, mode]
[, opacity]
[, preserveTransparency] [, feather]
[, wholePath] [, antiAlias])

Мы видим, что fillPath() (функция) принимает необязательные аргументы fillColor, mode, opacity, preserveTransparency, feathe, wholePath или antiAlias. Вызывая fillPath(), вы можете передать нигде ни от одного, ни от всех параметров к нему. Запятые в необязательном [] означают, что если этот параметр используется в дополнение к другим, вам нужна запятая, чтобы разделить его. (Здравый смысл иногда, конечно, но иногда некоторые языки, такие как VB, явно нуждаются в этих запятых, чтобы правильно определить, какой параметр отсутствует!). Поскольку вы не ссылались на документацию (и я не могу найти ее на странице скриптов Adobe ), действительно не существует способа узнать, какой формат ожидает Adobe API. Однако должно быть объяснение в верхней части самой документации, объясняющей соглашения, используемые внутри.

Таким образом, эту функцию можно было бы использовать многими способами:

fillPath() //Nothing passed
fillPath(#000000,RGB) // Black, in RGB mode
fillPath(#000000,RGB,50) // Black, in RGB mode, half opacity

//Now it gets tricky, this might ALSO be acceptable:
fillPath(#000000,50) // Black, no mode, half opacity

//OR
fillPath(#000000,,50) // Black, no mode, half opacity

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

69
ответ дан PenguinCoder 24 August 2018 в 19:45
поделиться

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

В скобках и т. Д. Обычно есть раздел условных условных обозначений, который должен объяснять точное использование внешних литералов; хотя EBNF , Regex и Диаграммы железных дорог почти повсеместны, поэтому вы должны быть знакомы с ними, чтобы понять большинство обозначений.

5
ответ дан fortran 24 August 2018 в 19:45
поделиться

Скобки означают, что свойство является необязательным. Имейте в виду, что если вы хотите установить свойство soem в ранге nTh, вам нужно либо объявить свойства для eading, либо объявить их как undefined:

fillPath() //good
fillPath ( someFillColor ) //good
fillPath ( someFillColor, mode ) //good
fillPath ( undefined, mode ) //good
fillPath ( mode ) //bad
fillPath ( undefined ) //really bad

Loic http: // www.loicaigon.com

3
ответ дан Jamiec 24 August 2018 в 19:45
поделиться

У меня был такой же вопрос некоторое время назад, и кто-то указал мне на Extended Backus-Naur Form .

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

1
ответ дан StevenKW 24 August 2018 в 19:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: