Det vigtige aspekt er ikke tabellen eller tabellerne, men selve forespørgslen, da det bestemmer kolonnerækkefølgen.
For eksempel hvis forespørgslen var baseret på SELECT * FROM your_table (og kolonnerne i tabellen blev defineret som id, sangnavn, sangår, sangsti) så ville kolonnen være, at markøren ville være i henhold til definitionen.
Men hvis du gjorde SELECT songname, songpath, songid, songyear FROM your_table;
Rækkefølgen ville være i henhold til SELECT udsagn, dvs. sangnavn (0), sangsti (1), sangid (2), sangår (3).
Det er dog et af problemerne med at bruge forskydninger, du er bundet til ordren i henhold til SELECT.
Hvis du nu brugte markørens getColumnIndex metode, så returnerer kolonneforskydningen i henhold til dets navn.
Så cursor.getString(cursor.getColumnIndex("songpath")); ville få sangsti-kolonnen uanset dens forskydning/position i markøren (HVIS MARKØREN INDEHOLDER DEN KOLONNE).
Når du husker dit tidligere spørgsmål, havde du dybest set SELECT songpath FROM your_table , Som sådan er der kun en enkelt kolonne i den resulterende markør, så du kan kun bruge get enten :-
cursor.getString(0);
eller :-
cursor.getString(cursor.getColumnIndex("songpath"));
Sidstnævnte er den anbefalede metode (MEN ideelt set har kolonnenavnene defineret som konstanter)
Sager kan dog blive mere komplicerede, for eksempel overvej
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
Dette ville returnere en enkelt kolonne ved navn myconfusingcolumn, der består af sangstien sammenkædet med sangnavnet. Det vil sige, at AS nøgleordet efterfølges af et alias for kolonnen (uden AS ville kolonnenavnet være endnu mere forvirrende/svært, da det ville være songpath||sangnavn) (dette eksempel er relativt simpelt).
En anden ting at være på vagt over for er, er tvetydige kolonner (duplikerede kolonnenavne) for eksempel, hvis du havde to tabeller sang og kunstner og sang den ekstra kolonne artist_id, så du har :-
sangen tabel med kolonner id , sangnavn , sangår , sangsti , artist_id
kunstnerne tabel med kolonner id og artist_name
og du brugte så
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Bemærk, at som id kolonne for kunstneren tabel, hvis den bruges i sætningen, skal den have et præfiks med det respektive tabelnavn, ellers ville der blive rejst en UTYDELIG kolonnefejl, dvs. SQL-parseren ville ikke vide hvilket id kolonne mener du.
Desuden ville du ende med en markør med kolonner :-
id , sangnavn, sangår, sangsti, artist_id, id , kunstnernavn
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).
For at opsummere/opsummere :-
Kolonnerne, rækkefølgen og navnet i en markør er helt afhængige af SELECT-forespørgslen. De vil have en offset og navn i henhold til forespørgslen. Når du får adgang til markøren, kan de underliggende tabelnavne ikke bruges, kun kolonnenavne eller forskydninger.
Det er mere fleksibelt at få adgang til kolonner efter deres navne i stedet for efter deres offstes . Det vil sige gør brug af markørens getColumnIndex metode, da den negerer behovet for at beregne forskydninger og især manglende genberegning, hvis en forespørgsel skulle ændres.
Brug af KONSTANTER til kolonnenavne vil sandsynligvis resultere i færre problemer såsom skrivefejl.
Yderligere
Brug af Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Får det usædvanlige resultat [{}], fordi mListSongs er hele beholderen til sangene. Du skal gå gennem hvert element og derefter hente egenskaberne/værdierne for hvert medlem/variabel fra elementet (Sangobjekt).