SQLight Datenbankvorgaben zwingend ?

Ich glaube den _id Primärkey legt SQLite immer selber an. (das sind ja dann immer auch die Long Ids dir du über den CursorAdapter zurückbekommst)
Dagegen kann man sich schlecht wehren.

Eigene Keys kannst du aber selber noch anlegen.

die spalte muss _id heißen, mit der cursoradapter weiß das es der künstliche primary key ist.

bisschen doof gelöst ich weiß, aber nicht wirklich schlimm oder doch?

mir definitiv auch aber das android team hatte sicher seine gründe warum es so festgelegt wurde

Entschuldigt bitte, wenn ich mich da einmische, aber was soll denn 'sprechender Primärschlüssel' genau bedeuten?
Sprechender als Tabelle._id geht es doch kaum.
Ihr meint doch hoffentlich nicht so einen unglaublich unverständlichen und redundanten Kram wie Artikel.artikelPS?

es geht darum in der programmierung zu wissen wo man gerade ist.

wenn der primärschlüssel jeder tabelle _id heißt kommt man möglicherweise irgendwann durcheinander.

normalerweise nennt man den primärschlüssel tabellenname_id

Zitat von ChampS

normalerweise nennt man den primärschlüssel tabellenname_id

Normalerweise spricht man die Tabelle direkt an und gibt das Feld dahinter an.
Also: Artikel._id.

Wie sieht denn da ein Primärschlüssel artikel_id aus?
Artikel.artikel_id?

Redundante Informationen sind redundant und Redundanz stört sowohl den Lesefluss als auch die Übersichtlichkeit.

Wenn ich mir eine Klasse 'Artikel' erstelle, dann sind die Felder dafür ja auch 'nummer', 'name', 'lieferant' und nicht 'artikelnummer', 'artikelname' und 'artikellieferant'. Denn das geht ja schon aus der Klasse hervor: Artikel.nummer, Artikel.name, Artikel.lieferant ist lesbarer als Artikel.artikelnummer, Artikel.artikelname, Artikel.artikellieferant.

Davon abgesehen: _id ist immer eine ID, egal welche Tabelle. Hast du also eine Hilfsfunktion, die alle IDs aus deiner Tabelle liest, dann kannst du sie abstrakt halten: ein Feld für den Tabellennamen und ein konstruiertes "SELECT _id FROM "+tableName;

Ebenso kann ich in dem oben genannten Beispiel auch noch eine Klasse Bestellung haben, mit Bestellung.nummer, Bestellung.datum und Bestellung.artikelliste.
Eine eventuelle Hilfsfunktion kann für eine Übersicht alle Nummern herausholen:

public Set<?> holeAlleNummern(List<InterfaceNummerierteObjekte> objektListe)
{
  Set<?> resultSet = new HashSet();
  for(InterfaceNummerierteObjekte objekt: objektListe)
  {
    resultSet.add(objekt.nummer);
  }
  return resultSet;
}

Tausche ich meine Objekte der objektListe aus, läuft weiterhin alles.
Hießen die Nummern aber Artikelnummer, Bestellnummer, Kundennummer, Lieferantennummer etc.pp. müsste ich jedes mal den Keypath angegeben.
Generell ist alles weniger fehleranfällig, was weniger Anpassungsaufwand erfordert.

Der CursorAdapter funktioniert auf jeder Tabelle, selbst wenn ich sie von Artikel auf Bestellung setze. Weil er sich auf _id als Primärschlüssel verlassen kann.
Also warum um Himmels Willen dazwischen funken wollen?

Viel spannender finde ich das Ursprungsproblem:

Zitat von khh

Nun hatte ich damit zwei identische Feldnamen, _id, die ich durch die Punktschreibweise, also tabellenname._id unterschieden hatte.
Leider hat das nicht funktioniert, das System hat mir die falschen Werte( id der falschen Tabelle) geliefert.

Magst du mal zusammengekürzt auf die id die Haupt- und die Subquery posten?
Das darf nämlich schlicht nicht passieren und deshalb vermute ich da einen Fehler im Ablauf - allerdings nicht von Seiten des CursorAdapters.