Android SQLite: is het een goede gewoonte om getColumnIndex aan te roepen bij het ophalen van waarden uit een tabel?

Op dit moment heb ik mijn code er zo uit zien:

SqlTables.java:

// Separate file
public enum SqlTables {
    TABLE_1("table_1"),
    .
    .
    .
    TABLE_N("table_n");
    final String name;
    private SqlTables(String name) {
        this.name = name;
    }
}

Table1Columns.java:

// Separate file
public enum Table1Columns {
    ...
}

SqlDatabaseInterface.java:

Cursor c = db.query(SqlTables.TABLE_1.toString(), null...);
final int indexId = c.getColumnIndexOrThrow(
        Table1Columns.ID.toString());
final int indexName = c.getColumnIndexOrThrow(
        Table1Columns.NAME.toString());
while (c.moveToNext()) {
    final String id = c.getString(indexId);
    final String name = c.getString(indexName);
}

Ik heb geen documentatie gevonden over hoe Android kolommen heeft toegewezen aan indices, dus hoewel ik heb bevestigd dat deze is gebaseerd op de volgorde waarin de kolommen in de query zijn vermeld, heb ik geen garantie dat dit 100% van de kolommen zal werken de tijd, of dat toekomstige updates dit gedrag zullen behouden. De voordelen van het gebruik van getColumnIndexOrThrow (...) is de garantie dat mijn indices altijd correct zullen zijn, zolang de kolommen waarnaar ze verwijzen in de query worden opgenomen. Het nadeel is dat het, naast de verveling, mijn code veel moeilijker maakt om te lezen en de duur van mijn methoden enorm vergroot. Aan de andere kant zou ik gewoon de indices kunnen opgeven zonder getColumnsIndexOrThrow aan te roepen, en dat zou mijn code verkorten, maar door het gebrek aan documentatie voelt het verkeerd.

1
Ik denk dat je het algemene idee hebt. Het gebruik van getColumnIndex() en getColumnIndexOrThrow() is langer om te typen, maar veiliger als u ooit opnieuw rangschikt of kleine wijzigingen in uw query aanbrengt.
toegevoegd de auteur Sam, de bron

1 antwoord

Nee, u moet zeker de kolomindexwaarden in uw code hard niet coderen. Als u dat doet, is uw database bijna niet te beheren (aangezien het wijzigen van de tabel ertoe kan leiden dat de indexwaarden veranderen).

Van wat ik kan vertellen, is uw code moeilijk te lezen omdat:

  1. U vermeldt uw code door onnodige oproepen naar toString() . Verwijder ze gewoon ... ze zijn volledig overbodig.

  2. U gebruikt het sleutelwoord definitief veel en het maakt uw code vervelend. Dit moet als voorzorgsmaatregel worden gebruikt in situaties waarin u per ongeluk de waarde van een variabele kunt wijzigen. Dit is niet een van die situaties ...

  3. U verspreidt eenvoudige instructies over meerdere regels. Gebruik gewoon een regel en het maakt het een stuk gemakkelijker om te lezen.

Dat gezegd hebbende, is er technisch niets mis met een van de bovenstaande codeermethoden. Ik wil alleen maar zeggen dat als je echt geïnteresseerd bent in het lezen van je code, je ze misschien als suggesties wilt beschouwen.

3
toegevoegd
Als u dat doet, is het vrijwel onmogelijk om wijzigingen aan te brengen in uw database. - Omdat ...
toegevoegd de auteur Robert Harvey, de bron
Ik zei alleen maar dat je antwoord niet af was. : P
toegevoegd de auteur Robert Harvey, de bron
Omdat, als hij ooit zijn databaseschema heeft gewijzigd (d.w.z. door een kolom aan een van zijn tabellen toe te voegen), er geen garantie is dat de gehele waarden gelijk blijven. Een subtiele bug als deze kan hem uren verspilling van tijdverspilling kosten. Daarom is het heel, zeer goed gebruik om de integerwaarden van de kolomindex tijdens runtime te controleren tijdens de uitvoering van het programma.
toegevoegd de auteur Alex Lockwood, de bron
Lol, nou ... totdat iemand kan wijzen op de fout in mijn redenering, sta ik achter dit antwoord en blijf 100% zeker dat dit antwoord correct is.
toegevoegd de auteur Alex Lockwood, de bron
@RobertHarvey, en trouwens, de auteur van dit boek is het ook met mij eens. :)
toegevoegd de auteur Alex Lockwood, de bron
Haha, oké ... nou dat is goed want voor een moment daar was ik als, "hmm ... is dit een strikvraag?". Hoe dan ook, ik heb mijn antwoord bijgewerkt. Bedankt :)
toegevoegd de auteur Alex Lockwood, de bron
Neem een ​​kijkje op Google I/O 2011 broncode ... het geeft u een goed idee van hoe u uw database klassen/constanten zou moeten ontwerpen. Ik zou enum s niet gebruiken voor de kolomnamen ... in plaats daarvan zou ik openbare statische laatste String constanten in mijn database class leveren. Het definiëren van uw kolommen als enum s is gewoon een extra stap toevoegen aan het proces en biedt geen voordelen ten opzichte van het gebruik van String constanten. Klopt dat?
toegevoegd de auteur Alex Lockwood, de bron
Bedankt voor het uitgebreide antwoord. Ik waardeer dat. Ter verduidelijking: ik heb een code toegevoegd om aan te geven waarom ik oproepen nodig heb voor Object.toString() . Ik plaatste mijn tabelnamen en kolomnamen in enums en de compiler (of tenminste de eclips) klaagt zonder hen. Mijn indexnamen zorgen ervoor dat de oproepen meer dan 80 tekens bevatten, dus heb ik de gesprekken verbroken om weer te geven hoe mijn code er in het algemeen uitziet. Wat de excessieve oproepen naar final betreft, ik weet het niet, maar ik voel me veilig, haha.
toegevoegd de auteur cesar, de bron