Важният аспект не е таблицата или таблиците, а самата заявка, тъй като това определя реда на колоните.
Например, ако заявката е базирана на SELECT * FROM your_table (и колоните в таблицата бяха дефинирани като идентификатор, име на песен, година на песен, път на песента), тогава колоната е, че курсорът ще бъде според дефиницията.
Въпреки това, ако сте направили SELECT songname, songpath, songid, songyear FROM your_table;
Поръчката ще бъде според SELECT изявление, т.е. име на песен (0), път на песен (1), песен на песен (2), година на песен (3).
Това обаче е един от проблемите с използването на компенсации, които сте обвързани с поръчката съгласно SELECT.
Сега, ако сте използвали getColumnIndex на курсора метод, който връща отместването на колоната според името му.
Така че cursor.getString(cursor.getColumnIndex("songpath")); ще получи колоната за пътя към песента, независимо от нейното изместване/позиция в курсора (АКО КУРСОРЪТ ВКЛЮЧВА ТАЗИ КОЛОНА).
Припомняйки предишния си въпрос, вие основно имахте SELECT songpath FROM your_table , Като такъв има само една колона в получения курсор, така че можете да използвате само get или :-
cursor.getString(0);
или :-
cursor.getString(cursor.getColumnIndex("songpath"));
Последният е препоръчителният метод (НО в идеалния случай имената на колоните са дефинирани като константи)
Въпросите обаче могат да станат по-сложни, например помислете за
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
Това ще върне една колона с име myconfusingcolumn, която се състои от пътя на песента, свързан с името на песента. Това е ключовата дума AS е последвана от псевдоним за колоната (без AS името на колоната би било още по-объркващо/трудно, тъй като би било песенна пътека||име на песен) (този пример е сравнително прост).
Друго нещо, от което трябва да внимавате, е, че са двусмислени колони (дублирани имена на колони) например, ако сте имали две таблици песен и изпълнител и песен, допълнителната колона artist_id, така че имате:-
Песната таблица с колони id , име на песен ,песенна година ,песенна пътека , идентификатор_изпълнител
Артистите таблица с колони id и име_на_изпълнител
и след това сте използвали
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Обърнете внимание, че като id колона на художница таблица, ако се използва в изявлението, тя трябва да бъде с префикс със съответното име на таблицата, в противен случай ще бъде изведена ДВУМНА грешка в колоната, т.е. SQL анализаторът няма да знае кой id колона имаш предвид.
Освен това ще получите курсор с колони :-
идентификатор , име на песен, година на песента, път на песента, идентификатор на изпълнител, id , име на изпълнител
csr.getLong(csr.getColumnIndex("id")); could get confused (I believe it actually gets the last AMBIGUOUS column)
long songid = csr.getLong(0); would get the id column from the song table.
long artistid = csr.getLong(5); would get the id column from the artist table.
long artistid = csr.getLong(4); would also get the artist_id same as (5).
За да обобщим/обобщим :-
Колоните, ред и име в курсора зависят изцяло от заявката SELECT. Те ще имат отместване и име според заявката. При достъп до курсора подлежащите имена на таблица не могат да се използват само имената на колоните или отместванията.
По-гъвкаво е достъпът до колони по имената им, а не по техните измествания . Това е да използвате getColumnIndex на курсора метод, тъй като отрича необходимостта от изчисляване на компенсации и по-специално липсващо повторно изчисляване, ако заявка бъде променена.
Използването на CONSTANTS за имена на колони вероятно ще доведе до намаляване на проблемите, като например грешки при въвеждане.
Допълнително
Използване на Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Ще получи необичайния резултат [{}], защото mListSongs е целият контейнер за песните. Трябва да преминете през всеки елемент и след това да получите свойствата/стойностите за всеки член/променлива от елемента (обект Song).
