Структура данных из MySql в FireBase (NOSQL db)

0

Я прочитал много учебников и вопросов и вопросов, связанных с stackoverflow, и я решил сконструировать структуру базы данных для Firebase. Я попытался сохранить его FLAT (это, кажется, довольно важное соображение). В то же время я не знаю всех возможных запросов, которые я буду применять к FireBase db (в конце этого сообщения я привел некоторые базовые примеры). Поэтому я ищу помощь того, кто уже работал с Firebase и сталкивается с основными проблемами людей, поступающих из реляционной базы данных

Предоставление следующей структуры Mysql

    TB_USER
    +----+--------+-------------+---------------+-----------------------------+------------------------+------------+
    | id |  name  |     bio     |     link      |           avatar            |         userId         | created_at |
    +----+--------+-------------+---------------+-----------------------------+------------------------+------------+
    |  1 | Fabian | bla...bla.. | www.site.com  | img_on_the_Server.jpg       | StringFromAuthFBGoogle | 20-02-2018 |
    |  2 | Sarah  | bla...bla.. | www.sarah.com | img_on_the_Server_Sarah.jpg | StringFromAuthFBGoogle | 18-02-2018 |
    |  3 | Carl   | bla...bla.. | www.carl.com  | img_on_the_Server_Carl.jpg  | StringFromAuthFBGoogle | 14-02-2018 |
    +----+--------+-------------+---------------+-----------------------------+------------------------+------------+


    TB_JOURNEYS
    +----+----------------------+----------------------+--------+------------+
    | id |     journey_name     |     description      | iduser | created_at |
    +----+----------------------+----------------------+--------+------------+
    | 28 | Traveling to India   | desc of India        |      2 | 21-02-2018 |
    | 34 | A week in China      | desc of China        |      1 | 21-02-2018 |
    | 46 | South America by car | incredible adventure |      3 | 22-02-2018 |
    +----+----------------------+----------------------+--------+------------+


    TB_STAGES
    +----+------------+------------+------------+--------------+------------------------------------------------+-----------------------+-----------------------+
    | id | id_journey |    date    |  latitude  |  longitude   |                      text                      |        picture        |         video         |
    +----+------------+------------+------------+--------------+------------------------------------------------+-----------------------+-----------------------+
    | 10 |         28 | 20-12-2017 | 46.3991665 | -117.0484223 | Fantastic day                                  | image_of_that_day.jpg | video_of_that_day.mp4 |
    | 20 |         28 | 23-12-2017 | 14.6082829 | -90.5528772  | Another beautiful day walking through the city | img_art.jpg           |                       |
    | 30 |         46 | 01-01-2018 | 45.462889  | 9.0376466    | Center of the city                             | pic.jpg               | video.mp4             |
    |    |            |            |            |              |                                                
    |                       |                       |
    +----+------------+------------+------------+--------------+------------------------------------------------+-----------------------+-----------------------+

Я придумал эту структуру FireBase

{
  "users": {
    "1": {
      "name": "Fabian",
      "bio": "bla...bla",
      "link": "www.site.com",
      "avatar": "img_on_the_Server.jpg",
      "userID": "StringFromAuthFBGoogle",
      "created_at": "20-02-2018"
    },
    "2": {
      "name": "Sarah",
      "bio": "bla...bla",
      "link": "www.sarah.com",
      "avatar": "img_on_the_Server_Sarah.jpg",
      "userID": "StringFromAuthFBGoogle",
      "created_at": "18-02-2018"
    },
    "3": {
      "name": "Carl",
      "bio": "bla...bla",
      "link": "www.carl.com",
      "avatar": "img_on_the_Server_Carl.jpg",
      "userID": "StringFromAuthFBGoogle",
      "created_at": "14-02-2018"
    }
  },
  "journeys": {
    "28":{
      "journey_name": "Traveling to India",
      "description": "desc of India ",
      "created_at": "21-02-2018",
      "iduser": 2
    },
    "34": {
      "journey_name": "A week in China ",
      "description": "desc of China ",
      "created_at": "21-02-2018",
      "iduser": 1
    },
    "46":{
      "journey_name": "South America by car",
      "description": "incredible adventure",
      "created_at": "22-02-2018",
      "iduser": 3
    }
  }, 
  "stages": {
    "10": {
      "id_journey": 28,
      "date": "20-12-2017",
      "latitude": "46.3991665",
      "longitude": "-117.0484223",
      "text": "Fantastic day ",
      "picture": "image_of_that_day.jpg",
      "video": "video_of_that_day.mp4"
    },
    "20": {
      "id_journey": 28,
      "date": "23-12-2017",
      "latitude": "14.6082829",
      "longitude": "-90.5528772",
      "text": "Another beautiful day walking through the city",
      "picture": "img_art.jpg"
    },
    "30": {
      "id_journey": 46,
      "date": "01-01-2018",
      "latitude": "45.462889",
      "longitude": "9.0376466",
      "text": "Center of the city",
      "picture": "pic.jpg",
      "video": "video.mp4"
    }
  }

}

Реальная проблема заключается в том, что я никогда не работал с NOSQL Db, поэтому я не знаю, может ли структура ответить на основные вопросы, на которые мы все должны ответить, пока мы используем реляционную базу данных. В приложении мне нужно будет получить все поездки, принадлежащие конкретному пользователю, и, конечно же, мне нужно будет восстановить все этапы, относящиеся к определенному пути. Я буду искать конкретного пользователя (поиск по имени)

Теги:
database
firebase-realtime-database

2 ответа

0

Кажется, вы на правильном пути:

  • Вы понимаете, что это не то же самое, что реляционная база данных.
  • Вы научились сохранять свою структуру данных плоской.

Некоторые уроки, основанные на том, что вы разделили:

  • В качестве ключа используются числовые (и часто последовательные) значения. Для лучшей масштабируемости он предпочитал использовать более уникальные значения для ключей, например:

    • Если вы используете Firebase Authentication, у каждого пользователя есть UID, который уже уникален. Так как каждый пользователь может только нас /users один раз, хранение их как /users/$uid означает, что вы автоматически применяете эту уникальность.
    • Если элементы еще не имеют уникального идентификатора, подумайте об использовании идентификаторов push-башен Firebase. Хотя они не так удобны для чтения для людей, как "индексы массивов", которые вы используете, у них есть преимущества вокруг масштабируемости и автономного поведения, которые делают их намного лучше подходящими для Firebase.
  • Для отношений "многие ко многим" вы, вероятно, захотите создать "узлы индекса" в обоих направлениях: например, от пользователей до поездок, в которых они находятся, и от поездки к пользователям, которые находятся на нем. Подробнее об этом см. В моем ответе здесь: От многих до многих отношений в Firebase
  • В общем, вы в конечном итоге моделируете свои данные для использования вашего приложения. Поскольку вы все еще не знаете все (что нормально), вы пока не можете определить окончательную модель данных. Это тоже хорошо. Вы будете расширять/изменять свою модель данных, пока вы обнаружите больше случаев использования.
  • Данные модели, как показано на экранах вашего приложения. Например, если у вас есть экран со списком имен пользователей, подумайте о том, есть ли список имен пользователей в вашей базе данных. Конечно, вы также можете загружать профили пользователей и отображать имена, но если у вас есть только имена, вы будете тратить меньше трафика.
  • Я не могу рекомендовать достаточно, чтобы вы читали моделирование данных NoSQL и наблюдали за разработчиками Firebase для SQL, которые представляют собой отличные интродукции/праймеры/открывающие глаза темы.
Поделиться
  • 0
    Привет Фрэнк, исходя из твоих соображений, я хотел бы получить некоторые разъяснения. Идея использовать более уникальные значения для ключей, я бы использовал «криптические» строки, сгенерированные Firebase, чтобы у пользователя с именем «Fabian» вместо ключа 1 он имел что-то вроде «L50G9QloKwPEvAaerSo» и, как следствие, в путешествии "Неделя в Китае" в iduser будет та же строка, что и упомянутая "L50G9QloKwPEvAaerSo". Та же концепция для путешествий и этапов?
  • 0
    Я бы назвал пользователей по их UID. Например, StringFromAuthFBGoogle
Показать ещё 3 комментария
0

Конечно, NoSQL нелегко для программистов, которые много лет работали с реляционными базами данных. Но, как и в SQL на себе, вы можете много программировать в приложении.

Вот пример: вы хотите найти текст в "Центре города".

SQL

SELECT * FROM TB_STAGES WHERE text='Center of the city'

NoSQL

Вы должны проходить через каждый объект, который включен в атрибут "путешествие", и проверить, соответствует ли текст тексту, который вы ищете.

Вот псевдокод, как это можно реализовать:

for(i = 0; i < journey.length; i++){
   curr = journey.get(i);
   if(curr.text == search_text){
      //Do what you want
   }
}

Надеюсь, это может помочь вам понять, что вы всегда можете сделать обходные пути для приложения/клиента при себе. Это не всегда лучшее решение, но оно работает.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню