Каков наилучший способ хранения и доступа к данным статической таблицы?

Question

Настоящий начинающий здесь,

Я ищу таблицу статических данных, в которой содержится около 300 ячеек. (Всего будет 12 отдельных таблиц)

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

Каков наилучший способ хранения этих данных в моем приложении? В настоящее время данные находятся в электронной таблице.

Данные выглядит следующим образом:

индекс 0, индекс 1, индекс 2, 3, индекс индекса 4, 5, индекс Index 6, 7, индекс индекс 8, Index 9

10,156,326,614,1261, 1890,3639,5800,10253,20914

20,107,224,422,867,1299,2501,3986,7047,14374 ... и т. Д.

Где номер в индексе нуль - это имя строки (введено пользователем), а числа после этого - значения, введенные пользователем.

Я хочу код, чтобы взять два числа (строки и значение), а затем возвращает строку, основанную на заголовке столбца (здесь как индекс 0 - 9)

последний хитрый бит, если пользователь вводит значение, находящееся между значениями, дает мне возможность использовать следующее самое высокое значение из данных. Например. если в строке «10» пользователь вводит 700, я хочу, чтобы код возвращал индексный заголовок для 1261.

Это имеет смысл?

Answer 1

Возможности бесконечны ...

• В коде как статический 2D массив
• XML
• JSON
• табуляцией текстовый файл
• Comma Текстовый файл
• Plist
• и т.д.

Все зависит от ваших потребностей и потребностей.

На минусах для каждого:

• статических 2D массив может потреблять некоторое количество памяти каждый раз, когда запускается приложение ...
• Файл будет включать в себя несколько дисков IO или обработки требований считывать значения из файл, хранящийся в Bundle.

На PROs для каждого:

• данных из статического массива будет БЫСТРО ...
• Обновление данных в файле может быть сделано на лету через Интернет.

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