#ios #swift #firebase #google-cloud-firestore
#iOS #swift #firebase #google-облако-firestore
Вопрос:
Попытка выяснить, как наилучшим образом структурировать данные в проекте Swift для отправки и извлечения из Firestore. Я видел несколько ответов на эту тему, но я все еще не совсем понимаю, как лучше всего обрабатывать актуальность структур с помощью карт / массивов Firestore. В идеальном сценарии было бы неплохо, если бы таблица хранилась как единый документ в базе данных FS с массивом или картой различных строк. Но эти строки также имеют несколько пар ключ-значение.
После структурирования кажется, что было бы идеально использовать то, как Firestore обрабатывает данные, вместо того, чтобы создавать какой-то сценарий синтаксического анализа (специально для строк). Спасибо всем, кто заглянул.
struct Row {
var rangeBegin: Int
var rangeEnd: Int
var content: String
}
struct Table {
var title: String
var sequencing: String
var time: Date
var rows: [Row]
}
Редактировать:
Итак, вот более подробная информация о том, как я в конечном итоге структурирую или запрашиваю данные…
Table
- Table Title (String)
- Rows (Array of Rows)
Row
- Row Content (String)
- Row Order (Int)
Table Group
- Table Group Title (String)
- Tables (Array of Tables)
У пользователя есть панель мониторинга со списком таблиц (с указанием заголовков таблиц). Они могут решить сгруппировать таблицы в группу таблиц (но это третичный). В конечном счете, когда пользователь переходит к подробному просмотру таблицы, он загрузит заголовок таблицы, а ниже перечислены все строки, связанные с этим содержимым, в правильном порядке.
При изменении строки содержимого строки данные таблицы будут обновлены / сохранены в БД. То же самое с изменением заголовка таблицы.
Если пользователь создаст новую таблицу, они будут переведены в пустое подробное представление с заполнителем заголовка таблицы и заполнителем содержимого строки 1. После их заполнения таблица будет сохранена. Таким образом, вывод текста из фокуса по большей части сэкономит.
Надеюсь, этот сценарий поможет.
Комментарии:
1. Не обязательно существует «наилучший способ» моделирования произвольных данных в Firestore. Моделирование должно следовать из способа, которым вы собираетесь запрашивать данные. Не зная заранее своих запросов, вы можете принять решение, которое позже приведет к проблеме. Сначала определите свои запросы, затем смоделируйте свои данные в соответствии с этими запросами, принимая во внимание известные ограничения Firestore.
2. @DougStevenson это отличный отзыв, учитывая, что он дает мне домашнее задание, а не решение. Это также имеет смысл, потому что я нахожусь в процессе создания нескольких запросов, и я продолжаю переходить туда и обратно, основываясь на том, что там работает, а что нет. В конечном счете, запросы могут быть такими, как редактирование содержимого в одном TextInput для одной строки.строка содержимого может вызвать необходимость обновления DB для этого одного конкретного значения ключа в FS. Обновление строки Table.title, а также … по сути, как только пользователь расфокусировал ввод.
3. Считается ли плохой практикой в Firestore определять поле с именем «строка» в качестве карты, а затем внутри него иметь несколько «row1» в качестве карты, «row2» в качестве карты и так далее?
4. Вероятно, лучше всего думать о Firebase как о коллекциях, документах и полях; конструкции «строка», «столбец» и «таблица» на самом деле не существуют в NoSQL. В вашем вопросе упоминается запрос данных ; это важный фактор, влияющий на то, как структурируются данные. Однако вы не сообщили нам, что такое ваши данные или что вы хотите из них извлечь. У меня есть список элементов, и я хочу запросить для каждого элемента, с которым синий цвет дает нам больше возможностей для работы. Можете ли вы заменить абстрактные примеры реальными примерами? Наконец, структуры пользовательского интерфейса и Firebase не связаны, поэтому подумайте, что MVC с Firebase является частью M) odel.