OK, t'avais pas parlé des prix ni des améliorations 
Je pense que le mieu est que tu fasses un barème à part.
Soit une table de référence supplémentaire (option, level, prix, amelioration_id, amelioration_percent), soit, si c'est possible, et c'est beaucoup mieu, à partir d'un calcul (t'as juste un prix de base à indiquer, et le type d'amélioration et le pourcentage de base à rajouter dans la table des options, sans détailler pour chaque niveau).
N'oublie pas notamment les fonctions logarythmiques qui te permettront d'avoir un prix de plus en plus cher en fonction du niveau, ou alors au contraire, des évolutions de moins en moins intéressantes.
Sinon, en gros ma requête fait fonctionne de la fonction suivante (par contre, comme j'ai dit, y'a peut-être des problèmes de syntaxe, je suis pas habitué à bosser avec MySQL) :
-> Elle récupère toutes les options (y compris celles où on n'a pour le moment pas de level - donc à 0), et indique le niveau prochain.
L'avantage réside notamment dans le fait que tu peux ajouter une option ou en supprimer une sans avoir ni à modifier la structure de la table, ni la requête, ni même le code.
Pour ce qui est de la complexité de la requête, en effet, bien que j'utilise des concepts assez basiques ici, si tu n'as pas reçu une formation SQL et que tu n'as pas d'expérience dans le domaine, c'est normal que tu n'y ait pas pensé. En effet, car même quand on connait ces possibilités, c'est assez difficile d'acquérir le réflèxe de les utiliser.
Mais la clé d'un code propre et maintenable, c'est avant tout :
-> Généricité la plus importante possible du modèle des données : on doit pouvoir ajouter et supprimer des informations sans changer la structure des données, et on doit pouvoir aisément intégrer de nouveaux paramètres. Ainsi, tu ne te retrouves jamais devant une base de données que tu dois reprendre à 0 parceque tu es bloqué par une évolution que tu n'arrives pas à implémenter.
-> Faire un maximum de traîtements, notamment ensemblistes et de regroupement dans les requêtes SQL. Le moteur de la base de données est conçu pour traîter ces instructions à la fois de façon simple et extrêment performantes. Même en optimisant à mort avec un langage compilé, tu n'arriveras "jamais" à reproduire les perfs du moteur de la base de données, et ce sera au prix d'un code bien plus complexe, donc difficile à maintenir.
Je te conseille fortement de te documenter sur deux sujets :
-> Analyse (au choix la méthode Merise ou UML. Je préfère la première, mais c'est aussi la seule que je sâche utiliser donc c'est normal ). Ca te permet de découper une problématique afin d'y trouver une solution, qui est parfois loin d'être celle qui sautait aux yeux à première vue. Au final, si tu appliques correctement ces méthodes, tu auras un modèle de données à la fois propre, simplifié, et maintenable. Tu n'auras plus qu'à le dénormaliser un peu pour l'optimiser, mais ça n'est pas indispensable.
-> Le langage SQL. Notamment les concepts ensemblistes (Les différents types de jointure, mais aussi UNION, INTERSECT, etc., même si tous ne sont pas supportés par tous les SGBD), et ceux de regroupement (GROUP BY). Ca permet généralement de simplifier au maximum l'algorythme qui va utiliser les données par la suite.
) il faut faire deux requetes :
s'pas grave
