Объекты по сравнению с массивами в JavaScript для пар ключ/значение
Вы можете пометить конкретные слова в обучающих фразах Dialogflow с помощью типа @ sys.any, который сможет захватить часть ввода. Затем вы можете получить его в качестве параметра.
Sys.any действительно полезен в этих типах абстрактных типов ввода, но потребует больше обучающих фраз, так как сопоставление только имени пользователя становится труднее.
Вместо использования имен пользователей, которые, кажется, не аутентифицированы для вашей службы, вы можете вместо этого взглянуть на вход в Google или OAuth. Приведенная выше рекомендация будет работать, но это не лучший способ использовать имена пользователей.
5 ответов
Каждое решение имеет свои варианты использования.
Я думаю, что первое решение хорошо, при попытке определить непосредственные отношения (такие как простое отображение), особенно если необходимо использовать ключ в качестве ключа поиска.
Второе решение чувствует самое устойчивое мне в целом, и я, вероятно, использовал бы его, если бы мне не был нужен быстрый ключ поиска:
- Это самоописывает, таким образом, Вы не должны зависеть ни от кого использующего людей, чтобы знать, что ключ является идентификатором пользователя.
- Каждый объект прибывает автономный, который лучше для передачи данных в другом месте - вместо двух параметров (идентификатор и имя), Вы просто раздаете людей.
- Это - редкая проблема, но иногда значения ключа не могут быть допустимыми для использования в качестве ключей. Например, я когда-то хотел отобразить преобразования строк (например, ":" к">"), но с тех пор ":" не допустимое имя переменной, я должен был использовать второй метод.
- Это легко расширяемо, в случае, если где-нибудь вдоль строки необходимо добавить больше данных к некоторым (или все) пользователи. (Извините, я знаю о Ваш "для пользы аргумента", но это - важный аспект.)
Третье было бы хорошо при необходимости в быстром времени поиска + некоторые упомянутые выше преимущества (раздавание данных, самоописывая). Однако, если Вам не требуется быстрое время поиска, это является намного более громоздким. Кроме того, так или иначе Вы рискуете ошибкой, если идентификатор в объекте так или иначе варьируется из идентификатора по людям.
Принятие данных никогда не будет изменяться, первое (отдельный объект), вариант является наилучшим.
Простота структуры означает, что это является самым быстрым для парсинга, и в случае маленького, редко (или никогда) изменяющий наборы данных, такие как этот, я могу только предположить, что она будет часто выполняться - в этом случае, минимальные издержки являются способом пойти.
На самом деле существует четвертая опция:
var people = ['Joe', 'Sam', 'Eve'];
так как Ваши значения, оказывается, последовательны. (Конечно, необходимо будет добавить/вычесть один---или просто поместить неопределенный как первый элемент).
Лично, я пошел бы с Вашим (1) или (3), потому что это будет самым быстрым для поиска кого-то идентификатором (O logn в худшем случае). Если необходимо найти идентификатор 3 в (2), Вы любой может искать его индексом (в этом случае, мой (4) в порядке), или необходимо искать — O (n).
Разъяснение: Я говорю, что O (logn) хуже, это могло быть, потому что, AFAIK и реализация могли решить использовать сбалансированное дерево вместо хеш-таблицы. Хеш-таблица была бы O (1), приняв минимальные коллизии.
Редактирование от nickf: я с тех пор изменил пример в OP, таким образом, этот ответ не может больше иметь столько же смысла. Извинения.
Постредактирование
Хорошо, постредактирование, я выбрал бы опцию (3). Это расширяемо (легкий добавить новые атрибуты), функции быстрые поиски, и может быть выполнено с помощью итераций также. Это также позволяет Вам идти от записи назад в идентификатор, должны Вы нуждаться к.
Опция (1) была бы полезна, если (a) необходимо сохранить память; (b) Вы никогда не должны идти от объекта назад к идентификатору; (c) Вы никогда не будете расширять хранившие данные (например, Вы не можете добавить фамилию человека),
Опция (2) хороша, если Вам (a) необходимо сохранить упорядочивание; (b) необходимо выполнить итерации всех элементов; (c) не должны искать элементы идентификатором, если он не отсортирован по идентификатору (можно сделать двоичный поиск в O (logn). Отметьте, конечно, если необходимо сохранить отсортированным затем, Вы оплатите стоимость на вставке.
Третий вариант является наилучшим для любого перспективного приложения. Вы будете, вероятно, хотеть добавить больше полей к своей записи человека, таким образом, первая опция будет неподходящей. Кроме того, вероятно, что Вы будете иметь большое количество людей для хранения и захотите искать записи быстро - таким образом дамп их в простой массив (как сделан в опции № 2), не хорошая идея также.
Третий шаблон дает Вам опцию использовать любую строку в качестве идентификатора, иметь сложные структуры Человека и получить и установить рекорды человека в постоянное время. Это - определенно способ пойти.
Одной вещью, в которой испытывает недостаток опция № 3, является стабильное детерминированное упорядочивание (который является позитивным аспектом опции № 2). Если бы Вам нужно это, я рекомендовал бы сохранить заказанный массив идентификаторов человека как отдельная структура для того, когда необходимо перечислить людей в порядке. Преимущество состояло бы в том, что можно сохранить несколько таких массивов для различных упорядочиваний того же набора данных.
Учитывая Ваше ограничение, что у Вас только когда-либо будет имя как значение, я выбрал бы первую опцию. Это является самым чистым, имеет наименее служебное и самый быстрый взгляд.