РЕДАКТИРОВАТЬ: Я нашел проблему, которая была совершенно не связана с ниже. Именно из-за того, что я проводил побитовое сравнение, я не смог упомянуть ниже - я подумал, что это неактуально - я удалил это (и нашел альтернативное решение), и мой запрос теперь выполняется на устройстве <1 секунда. </strong>
В настоящее время я работаю над своим первым приложением для iPhone, которое идет хорошо. Это приложение для просмотра расписания поездов для определенной сети поездов. У меня есть база данных SQLite, содержащая около 11 000 строк, в которых хранятся данные, которые я использую для планирования поездки.
Структура таблицы следующая:
from depart to arrive trainid
--------------------------------------------------
STNA 06:20 STNB 06:24 TRAINA
STNB 06:25 STNC 06:29 TRAINA
STNC 06:30 STND 06:35 TRAINA
STNA 07:23 STNC 07:30 TRAINB
STNC 07:32 STNE 07:40 TRAINB
STNE 07:41 STNF 07:50 TRAINB
Поля FROM и TO представляют собой трехбуквенные IDS станций на маршруте, поля DEPART и ARRIVE являются временными метками, а поле TRAINID является идентификатором, общим для всех станций конкретного поезда. поездка (т. е. все остановки на поезде 06:20 из STNA в STND имеют один и тот же поезд).
Когда я хочу, например, узнать, какие поезда доставят меня из STNA в STND, я делаю следующий запрос:
SELECT t1.from, t1.depart, t2.to, t2.arrive, t1.trainid FROM trains t1, trains t2 WHERE t1.trainid = t2.trainid AND t1.depart < t2.arrive AND t1.from = 'STNA' AND t2.to = 'SNTD';
Это само присоединяется к таблице поездов (часть t1.depart STND вместо STND-> STNA).
Это работает хорошо, однако на iphone это очень медленно (хорошо, так что вы можете сказать, что не очень хорошо), для запуска требуется около 10 секунд (возвращает около 80 результатов). Я понимаю, что это, скорее всего, из-за того факта, что таблица с 11 000 строк соединяется сама с собой - но я не знаю, как мне это оптимизировать. Кстати, для этого я использую FMDB.
Я думаю, мне нужно идти по маршруту CoreData, но, как новичок на платформе iPhone, я надеялся избежать этого для этого проекта. Как вы думаете, CoreData предложит значительные преимущества в производительности в этом сценарии? Как человек с чисто SQL-опытом, я был бы признателен за любые советы о том, как лучше всего продолжить работу с CoreData. Могу ли я выполнять самостоятельные объединения с CoreData или мне нужно моделировать данные по-другому?
EDIT:
Это вывод объяснения по запросу, который я выполняю:
add opcode p1 p2 p3 p4 p5 comme
--- ------------ ----- ----- ----- ---------------------------------------- ----- -----
0 Trace 0 0 0 00
1 String8 0 1 0 GRY 00
2 String8 0 2 0 FST 00
3 Goto 0 47 0 00
4 OpenRead 0 2 0 7 00
5 OpenRead 2 377 0 keyinfo(1,BINARY) 00
6 OpenRead 1 2 0 7 00
7 OpenRead 3 1107 0 keyinfo(1,BINARY) 00
8 IsNull 1 42 0 00
9 Affinity 1 1 0 ab 00
10 SeekGe 2 42 1 1 00
11 IdxGE 2 42 1 1 01
12 IdxRowid 2 3 0 00
13 Seek 0 3 0 00
14 Column 0 6 4 0 00
15 IsNull 4 41 0 00
16 Affinity 4 1 0 db 00
17 SeekGe 3 41 4 1 00
18 IdxGE 3 41 4 1 01
19 IdxRowid 3 3 0 00
20 Seek 1 3 0 00
21 Column 0 5 3 00
22 Column 1 5 5 00
23 Ne 5 40 3 collseq(BINARY) 6a
24 Column 0 3 5 0 00
25 RealAffinity 5 0 0 00
26 Column 1 3 3 0 00
27 RealAffinity 3 0 0 00
28 Ge 3 40 5 collseq(BINARY) 6b
29 Column 1 2 3 00
30 Ne 2 40 3 collseq(BINARY) 69
31 Column 2 0 6 00
32 Column 0 3 7 0 00
33 RealAffinity 7 0 0 00
34 Column 1 2 8 00
35 Column 1 4 9 0 00
36 RealAffinity 9 0 0 00
37 Column 0 5 10 00
38 Column 0 6 11 0 00
39 ResultRow 6 6 0 00
40 Next 3 18 0 00
41 Next 2 11 0 00
42 Close 0 0 0 00
43 Close 2 0 0 00
44 Close 1 0 0 00
45 Close 3 0 0 00
46 Halt 0 0 0 00
47 Transaction 0 0 0 00
48 VerifyCookie 0 8 0 00
49 TableLock 0 2 0 stops 00
50 Goto 0 4 0 00