En bref : non, aucun moyen.
Pourquoi ?
SQL, d'une manière générale, gère des entités (tables) assimilables à des ensembles. Un "SELECT * FROM mytable" est susceptible de renvoyer les rangées correspondantes dans n'importe quel ordre (et éventuellement dans un ordre différent à chaque invocation) à défaut d'une clause ORDER BY.
De ce fait, SQL (SQLite ici) n'a aucune notion d'ordre de création et ne peut donc répondre de façon fiable à ta question. On pourrait penser que SQLite stocke les rangées de sqlite_master "dans l'ordre" de création/modification, mais un rapide coup d'oeil dans une base ayant un peu évolué au cours du temps montre qu'il n'en est absolument rien. De toute façon, c'est un détail d'implémentation non documenté, susceptible de changements d'une version à l'autre et donc sur lequel il ne faut pas faire reposer une décision.
EDIT: j'ajoute pour clore ce point qu'il n'y a pas non plus de rapport direct entre ces deux résultats :
Code : Tout sélectionner
select rowid, * from sqlite_master where type = 'table' order by rowid desc limit 1;
pragma schema_version;
La première requête ne renvoie pas la drenière table créée et la seconde requête ne "pointe" pas vers une chose plutôt qu'une autre. De plus, SQLite peut parfaitement changer demain l'implémentation interne de sqlite_master et utiliser une hashtable au lieu d'un B-Tree / rowid.
Par contre, je m'interroge sur le besoin que tu as : c'est toi qui doit connaître la liste de tes tables et si, comme ton exemple semble le faire croire, tu crées des tables similaires à la volée (d'où le LIKE '%RP%'), c'est que ton schéma n'est vraisemblablement pas bon.
EDIT bis : Quand on en arrive à traiter le nom de tables (ou tout autre nom du schéma) comme des variables, c'est une excellente indication que ce schéma n'est pas (assez) normalisé.
Pose-toi la question : qu'est-ce qui différencie les tables LIKE '%RP%' entre elles ? Disons pour rester générique que c'est la caractéristique <truc>. Et bien les différentes valeurs de <truc> doivent former une colonne distinctive d'une seule et unique table RP.
Du coup le problème disparaît immédiatement. Si tu veux savoir quand on a créé ou modifié en premier ou en dernier une rangée de caractéristique <truc>, cela devient une partie d'une clause WHERE ou HAVING de tes SELECT, à condition bien sûr de stocker un marquer de temps dans cette table. Autre solution, créer un trigger qui enregistrera l'information temporelle dans une table séparée.
C'est le contexte qui dictera le meilleur moyen de procéder en pratique, mais ce choix relève plus de l'optimisation que du design, donc à faire plutôt tardivement.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Vraiment sqlite c'est top 