Обзор

Структура вашего фида сквозных данных Ordering определяется схемой реляционного запаса . Поток сквозных данных Ordering состоит из следующих объектов верхнего уровня:

На следующей диаграмме показано, как сущности Service , Restaurant и Menu представляют один ресторан:

Диаграмма отношений классов меню ресторанного сервиса
Рисунок 1. Общая взаимосвязь объектов сквозного потока данных Ordering: Сервис, Ресторан и Меню.

Общие рекомендации

  • Рестораны на файл : каждый файл данных должен представлять один ресторан со связанными с ним объектами Service и Menu . Используйте имена файлов, которые помогут вам найти файл для ресторана.

  • Формат файла данных : файлы данных должны быть отформатированы в файлы JSON, разделенные символами новой строки ( формат ndjson ).

  • Значения DateTime и Time . Для свойств, которым требуется значение DateTime или Time , используйте форматы, указанные в форматах DateTime и Time . Например, 2017-05-01T06:30:00+05:30 для DateTime и T08:08:00+05:30 для Time .

  • Идентификаторы : используйте свойство @id для идентификации всех уникальных объектов внутри типа объекта. Максимальная длина — 300 символов. @id — это уникальный идентификатор объекта этого типа, но идентификаторы разных объектов могут перекрываться. Например, предположим, что вы определяете сущность Service со свойством @id , имеющим значение a16 . Вы не можете создать другую сущность Service с @id a16 . Однако вы можете использовать a16 в качестве значения @id сущности Menu .

  • Генерация идентификаторов : сохраняйте стабильные идентификаторы — не используйте UUID или иным образом меняйте/рандомизируйте идентификаторы между загрузками каналов. Это упрощает поддержку проблем, связанных с сущностями.

  • Нулевые значения : не используйте значение null вместо объектов. Если объект не является обязательным, его необходимо исключить из фида.

Клиентские библиотеки

Генератор клиентского кода в разделе «Инструменты» доступен для проверки вашего сквозного канала данных Ordering.

,

Структура вашего фида сквозных данных Ordering определяется схемой реляционного запаса . Поток сквозных данных Ordering состоит из следующих объектов верхнего уровня:

На следующей диаграмме показано, как сущности Service , Restaurant и Menu представляют один ресторан:

Диаграмма отношений классов меню ресторанного сервиса
Рисунок 1. Общая взаимосвязь объектов сквозного потока данных Ordering: Сервис, Ресторан и Меню.

Общие рекомендации

  • Рестораны на файл : каждый файл данных должен представлять один ресторан со связанными с ним объектами Service и Menu . Используйте имена файлов, которые помогут вам найти файл для ресторана.

  • Формат файла данных : файлы данных должны быть отформатированы в файлы JSON, разделенные символами новой строки ( формат ndjson ).

  • Значения DateTime и Time . Для свойств, которым требуется значение DateTime или Time , используйте форматы, указанные в форматах DateTime и Time . Например, 2017-05-01T06:30:00+05:30 для DateTime и T08:08:00+05:30 для Time .

  • Идентификаторы : используйте свойство @id для идентификации всех уникальных объектов внутри типа объекта. Максимальная длина — 300 символов. @id — это уникальный идентификатор объекта этого типа, но идентификаторы разных объектов могут перекрываться. Например, предположим, что вы определяете сущность Service со свойством @id , имеющим значение a16 . Вы не можете создать другую сущность Service с @id a16 . Однако вы можете использовать a16 в качестве значения @id сущности Menu .

  • Генерация идентификаторов : сохраняйте стабильные идентификаторы — не используйте UUID или иным образом меняйте/рандомизируйте идентификаторы между загрузками каналов. Это упрощает поддержку проблем, связанных с сущностями.

  • Нулевые значения : не используйте значение null вместо объектов. Если объект не является обязательным, его необходимо исключить из фида.

Клиентские библиотеки

Генератор клиентского кода в разделе «Инструменты» доступен для проверки вашего сквозного канала данных Ordering.

,

Структура вашего фида сквозных данных Ordering определяется схемой реляционного запаса . Поток сквозных данных Ordering состоит из следующих объектов верхнего уровня:

На следующей диаграмме показано, как сущности Service , Restaurant и Menu представляют один ресторан:

Диаграмма отношений классов меню ресторанного сервиса
Рисунок 1. Общая взаимосвязь объектов сквозного потока данных Ordering: Сервис, Ресторан и Меню.

Общие рекомендации

  • Рестораны на файл : каждый файл данных должен представлять один ресторан со связанными с ним объектами Service и Menu . Используйте имена файлов, которые помогут вам найти файл для ресторана.

  • Формат файла данных : файлы данных должны быть отформатированы в файлы JSON, разделенные символами новой строки ( формат ndjson ).

  • Значения DateTime и Time . Для свойств, которым требуется значение DateTime или Time , используйте форматы, указанные в форматах DateTime и Time . Например, 2017-05-01T06:30:00+05:30 для DateTime и T08:08:00+05:30 для Time .

  • Идентификаторы : используйте свойство @id для идентификации всех уникальных объектов внутри типа объекта. Максимальная длина — 300 символов. @id — это уникальный идентификатор объекта этого типа, но идентификаторы разных объектов могут перекрываться. Например, предположим, что вы определяете сущность Service со свойством @id , имеющим значение a16 . Вы не можете создать другую сущность Service с @id a16 . Однако вы можете использовать a16 в качестве значения @id сущности Menu .

  • Генерация идентификаторов : сохраняйте стабильные идентификаторы — не используйте UUID или иным образом меняйте/рандомизируйте идентификаторы между загрузками каналов. Это упрощает поддержку проблем, связанных с сущностями.

  • Нулевые значения : не используйте значение null вместо объектов. Если объект не является обязательным, его необходимо исключить из фида.

Клиентские библиотеки

Генератор клиентского кода в разделе «Инструменты» доступен для проверки вашего сквозного канала данных Ordering.

Далее
Быстрый старт