Как правильно разложить по таблицам вот такой объект данных?
У каждого юзера может быть много объектов travels. Каждый travels уникален и никогда не повторяется ни у юзера ни у других юзеров.

{
"user_name":"Jon_12",
"first_name":"Jon",
"last_name":"Getsby",
"user_id":2438207,
"travels" : {
   "type":"Vacation",
   "id":1,
   "city":[
       "Toronto",
       "Sidney"
       ],
   "rivers":[
       "Missisipy",
       "Amazonka"
       ],
   "comment":true,
   "good":[
       "good people",
       "good weather"
       ],
    "bad":[
       "expensive",
       "long away"
       ]
    }
}

Я понимаю, что будет табличка _users и табличка _travels и у _users будет связь с _travels.

Не пойму как организовать _travels...
1. Как табличку в которой будут лежать отдельные объекты по ключам-id юзера?
2. Или как наборы объектов _travels которые будут лежать внутри массива по ключу юзера...

В первом случае, при выдаче данных пользователя нужно будет выбирать из _travels все объекты по id пользователя и джоинить к основным данным...

Во втором случае, брать в _travels массив с объектами по id-ключу юзера...

Как будет правильно и оптимизированно?

Положи это в граф

Хотя сейчас вылезут отпетые ярые олдфаги 65-го года рождения, которые скажут, что всё нужно хранить в реляционных базах данных

И вообще у меня форма не нормальная

В граф это как? )

Neo4j, например. Почитай

Ок. Спс. Пошёл читать. )

Как набор объектов, у которых свой идентификатор. Как ты по идентификатору пользователя пихнешь больше одной записи?

На кой пёс отношение фиксированной глубины тащить в граф?

Я бы понял там была цепочка друзей произвольной длины

Хм.. Это да..
Получается, в первом варианте, каждая отдельная поездка будет лежать отдельной записью с уникальным id + id юзера которой принадлежит...

А во втором варианте - отдельной записью по id-юзера - массив с поездками этого юзера...

Но что-то второй вариант мне не очень нравится...
А первый вариант будет затратен в плане поиска всех поездок юзера по таблице...

Может есть ещё варианты?

Почему затратен?

Индекс на traveller_id и вперед

Ок. Спс.

Ты што, серьезно не понимаешь? Или ты просто только академически занимаешься базами?

Серьезно не понимаю

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

На самом деле этот вариант мне очень подходит и нравится. )

Графы я глянул, но разбираться с ними сейчас некогда...

Единственный непонятный  момент у меня был с производительностью. Но индексирование решает.. )

User же...
Но, к сожалению, это - ключевое слово языка SQL