SQLite - base de données toutes plateformes

[boubouk50]

Salut la compagnie,

Aujourd'hui, j'ai le plaisir de découvrir les joies de la BDD. Je me documente à droite à gauche, je comprends le principe: base/table/champs/entrée, la lecture/écriture. Par contre, concernant la mise en place, je nage un peu. Pour moi, tout ça reste un peu trop statique: J'ai des tableaux, je vais chercher des infos.(<- lire Point)
Ce que je souhaiterai faire, et que je n'ai pas trop pigé, c'est (oh mon dieu je ne sais même pas l'expliquer...). Je vais faire un exemple:
J'ai un catalogue de voitures téléguidées (bon, en réalité c'est pas ça, mais c’est pour attirer le chaland).
Ces voitures sont définies par: leur nom, leur modèle 3D, les couleurs possibles, les jantes possibles et les motorisations possibles.
Il existe pas mal de modèles qui partagent les mêmes attributs Jantes ou couleurs ou motorisations.
D'autres modèles qui ont des attributs spécifiques ou uniques. D'autres qui ne peuvent avoir certaines jantes en fonction de la motorisation.
Vous voyez le schéma j'espère: je n'arrive pas exactement à voir comment agencer cela. Je ne peux pas dire: tel modèle, telles jantes, telles couleurs, telles motorisations.
D'une je ne sais pas comment créer cette BDD. Deux, je ne souhaite pas rentrer tout cela à la main par voiture, vu qu'il y a beaucoup de doublons.

Donc dans ma vision des choses, je verrais du coup des champs spécifiques qui permettent de faire le choix des possibilités pour moi. Par ex, au lieu que ma voiture est un attribut motorisation, elle aurait un attribut Moteur qui lui "irait chercher" les bonnes motorisations associées. Et là, je commence à me perdre...

Si quelqu'un familier de la BDD (et surtout qui a compris ce que j'essaie d'expliquer) pouvait m'éclairer ma lanterne par des schémas, des métaphores, des tutos ou bien une vraie explication, j'en serai ravi et je boirai une bière à sa santé.

Merci,
la bise au chat.

[MasterNovice]

Je pense qu'il doit y avoir plusieurs moyens de faire. Si je t'ai bien suivi, je créerais donc ma table moteur et dans cette table j'ajouterais une colonne Id du véhicule qui pourrait avoir ce moteur. Tu n'aurais plus qu'à récupérer tout les moteurs par id véhicule ensuite.

Exemple :

Moteur_A Vehicule_A
Moteur_A Vehicule_C
Moteur_A Vehicule_D
MOTEUR_B Vehicule_B

Etc... Je ne sais pas si je suis très clair.

[Selsynn]

Je me sens un peu obligé de répondre.

1) pourquoi nommer ton sujet SQLite ? Parce que c'est pas vraiment une base de données (comprendre, c'est pas une vraie base de données, c'est un fichier qui est géré comme une base de données, mais enfin, soyons pas bdd-raciste)

2) Veux-tu réellement une base de données ? Ne veux-tu pas plutôt un fichier XML/JSON contenant la définition de tes voitures.

On va reprendre les bases (et c'est valable (surtout) hors Unity) :

Une base de données, c'est un moyen de stocker des informations qui vont changer au fil du temps, avec une gestion plus ou moins poussée de l'accès concurrentiel.
Pour dialoguer entre le code et la "base de données" on utilise un autre language qui s'appelle le SQL (et c'est de syntaxe très simple, mais j'y reviendrais)

Une base de données peut être modélisé dans un "langage" qui s'appelle Merise, mais c'est pas très connu, donc je vais pas m'étendre là-dessus.

Comment je modélise et transforme des "objets" en modèle SQL ?
Un modèle SQL ?

Plusieurs boites indépendantes qui chacune (pour simplifier et éviter les erreurs)
* doit avoir une PRIMARY KEY (index auto-incrément par défaut)
* peut avoir autant de champs qu'elle veut

Chaque champ est composé de :
* un nom (qui te sert et te parle à toi). SANS CARACTERE SPECIAL ! TOUT EN MINUSCULE (je ne connais pas le moteur de Unity, mais aucun moteur de base de données ne gère correctement les majuscules dans les noms des champs
* un type (entier, text...)
* une valeur par défaut (non obligatoire, des fois elle est sous-entendu, par exemple pour le texte, c'est une chaine vide)
* savoir si le champ peut être nul (refusera l'insertion de l'entrée si la valeur est nulle)

J'ai peur de t'avoir perdu.
En gros, imagines pleins de tableaux. Les champs, c'est les colonnes, les noms dont je parle, c'est le nom de la colonne. (juste qu'elle est typée, cette colonne)
Et un tableau, c'est une table SQL.
Un autre tableau, c'est une autre table SQL.

Et le truc magique de SQL, c'est le "relationnel" tu peux dire que le type de l'un de tes champs, c'est un autre tableau, cad une autre table SQL

Comment je parle le SQL ? (là encore c'est du pure SQL, pas Unity-based)
Simple, très simple (surtout si on veut faire des opérations simple)

Création de la table (à faire avant la toute première utilisation)

Code : Tout sélectionner

CREATE TABLE nom_de_ma_table
( nom_de_mon_champ TYPE_DU_CHAMP [i]options[/i],
nom_de_mon_champ2 TYPE_DU_CHAMP2 [i]options2[/i]);

(les options sont le fait d'être une référence vers une autre table, ou un auto-incrément...)

Insertion d'une valeur

Code : Tout sélectionner

INSERT INTO nom_de_ma_table (nom_de_mon_champ, nom_de_mon_champ2) VALUES (valeurChamp1, valeurChamp2);

Lecture d'une valeur

Code : Tout sélectionner

SELECT * FROM nom_de_ma_table WHERE [i]condition[/i];

Les conditions vont être un champ égale à une valeur ou tout autre élément de comparaison.

Modification d'une valeur

Code : Tout sélectionner

UPDATE nom_de_ma_table SET nom_de_mon_champ = nouvelle_valeur;

Bon et mes voitures dans tout ça ?
Je te propose par exemple la chose suivante (pour te donner une idée et après tu pourras l'appliquer comme t'as envie)
en gras : nom de la classe
en italique : option du champ
en souligné : nom du champ
en majuscule : mot clefs tel qu'utiliser en SQLite

voitures :
id INTEGER PRIMARY KEY,
couleur TEXT NOT NULL,
nom TEXT NOT NULL,

jantes :
id INTEGER PRIMARY KEY,
voiture_id INTEGER,
nom TEXT NOT NULL
machin TEXT/INTEGER....
FOREIGN KEY(voiture_id) REFERENCES voiture(id)

Bon, le machin, c'est parce que pour moi, une jante, c'est une jante, et que je vois pas de différence, mais je te laisse choisir tes champs. Tu veux que je te présente la classe motorisations ou tu as compris le principe ?
J'ai essayé d'être clair, mais les bases de données font un peu trop partie de ma vie pro pour que je sois peut être suffisamment clair pour un novice.

Edit : j'ai pas encore joué avec ça dans Unity, donc pour cette partie, je laisserais quelqu'un d'autre répondre

ATTENTION FOREIGN KEY est utilisable que depuis la version 3.6.19 (source Wikipedia https://fr.wikipedia.org/wiki/SQLite)

[MasterNovice]

Bah là niveau vrai explication... La mienne fait figure de brouillon. Merci pour le post très intéressant

[Selsynn]

T'as répondu plus vite que moi ^^
Je sais même pas si je suis vraiment claire. J'attends son retour pour savoir si quelque chose est à approfondir.

[NDrew]

Ya du bon et du moins bon dans l'explication de Selsynn.

Un des objectifs de la base de données est de réduire la redondance (en plus de stocker l'information bien sur) Comme dit plus haut, les SGBD(systeme de gestion de base de données) sont spécialisé dans l'accès concurrentiel, les transactions, la sécurité.

j'aurai du mal a faire un texte bien construit pour t'expliquer, mais tu dois savoir que je passe mes journées sur le chat

Donc pour moi, une jante n'a pas a savoir a quelle voiture elle appartient, ça permet de pouvoir créer des jantes sans avoir a avoir de voiture pour les attacher. C'est un peu comme quand on programme en objet et qu'on essais de réutiliser le code, ici on veut réutiliser les structures et surtout éviter de dédoubler l'information.

Dans ton exemple de voiture je verrais des tables qui permettent de stocker les composantes dont tu as besoins pour construire des voitures. Je verrais également des tables dans lesquelles tu indique ce qu'est vraiment une voiture et quelles composantes elle utilise. Enfin on pourrait avoir des tables ou tu stocke les possibilités, des templates quoi?

Enfin, si jamais tu fais le choix d'utiliser des bases de données, sache que pour éviter d'apprendre la syntaxe SQL tu peux utiliser un ORM (Object relational mapper) qui permet de faire la liaison entre tes objets c# et leurs données dans la base de donnée.

Je crois que malgré tout on manque d'info pour te dire si oui ou non tu as besoin d'une base de donnée.

[Silverglade]

Et si c'est le cas et dans le cas ou tu ne le saurais pas déjà, j'ai souvenir que les liaisons bdd/unity se font uniquement (avant la 4.5 en tous cas, après aucune idée) via php ce qui est assez chiant niveau "touche-touche" faut l'avouer mais pas compliqué à mettre en place, l'utilisant de façon soft personnellement.

[Moi 1971]

Bonjour Boubouk.

Tu maitrises la programmation OO, donc il faut que tu imagines tes tables comme tes objets Unity(C#). Les champs de tes tables comme les propriétés de tes objets Unity(C#). Les relations entre tes tables comme des fonctions/méthodes de tes objets Unity(C#)

Mais, la vraie question (elle t'a été posée par selsynn) est : As-tu vraiment besoin d'une BDD relationnelle?
Parce que, pour bien faire les choses, ta base de données devra être créée en fonction de tes besoins. Il n'existe pas de modèle qui aille pour toutes les situations. Donc il va falloir que tu détailles tes besoins précisément pour créé, un, les modèles de données et deux les relations entres les données.

L’intérêt de la BBD, c'est le relationnelle. Mais normalement, ton code C# peut tout à fait le faire ( Et ce sera plus facile et efficace car tu maitrises le c#)

Donc là j'ai répondu à ton un "..D'une je ne sais pas comment créer cette BDD".
Maintenant le deux "..Deux, je ne souhaite pas rentrer tout cela à la main par voiture, vu qu'il y a beaucoup de doublons." :
Bha si. va falloir rentrer les données... c'est la saisie, obligatoire. Le relationnelle améliore le temps de la lecture des données mais pas la saisie... Si tu créé une voiture va falloir dire le nombre de porte, le type de la voiture, les moteurs,... que tu tapes "4" portes dans un fichier Xlm, dans une table monolithique Sqllight ou dans une basse de donnée relationnelle Oracle... c'est toujours "4".

En tout cas, si tu veux une base de données de type relationnelle, pour que nous puissions t'aider, il va falloir que tu nous donnes précisément toutes les infos.
Pour commencer on va prendre l'exemple d'une voiture 123456 qui peut recevoir deux types de moteur, un 4 cylindre 2.5 turbo et un V6 atmo.
TABLE "voiture"
CHAMP "id_voiture", primaryKey/notNull
CHAMP "nom" , Varchar

TABLE "moteur"
CHAMP "id_moteur", primaryKey/notNull
CHAMP "nom" , Varchar

TABLE "relation_voiture_moteur"
CHAMP "id_moteur"
CHAMP "id_voiture"
+clef unique sur le couple "id_moteur/id_voiture" pour ne pas avoir de doublon.

La relation "quelle type de moteur va dans la voiture 123456? " est donné par la table "relation_voiture_moteur". Avec une requête SQL du genre : SELECT M.id_moteur FROM moteur M, relation_voiture_moteur R WHERE R.id_voiture = 123456;

(PS : 123456 est l'id_voiture concerné que l'on connait forcément avant vu la question que l'on s'est posé)
(PS2 : La requête SQL c'est pour expliquer, elle est syntaxiquement fausse...)

Donc si la voiture a deux moteurs possibles, c'est dans la base "relation_voiture_moteur" qu'il y aura deux lignes. Le doublon d'information ce trouve là.

Bon j'arrête là, c'est trop long.

Edit : Heu... je me demande si ... il se peut (mais je ne me souviens plus) que la requête doit contenir l'information : "R.id_moteur = M.id_moteur" dans la clause WHERE pour faire le lien.. mais bon de toute façon elle n'est pas exacte...)

[boubouk50]

Bonjour,
et merci pour les pavés de bon matin.

Alors dans la tas, je voyais plutôt quelque chose comme l'explique NDrew, ça me parle, et le coup de la table intermédiaire, c’est l'info qui me manquait.

Dans ton exemple de voiture je verrais des tables qui permettent de stocker les composantes dont tu as besoins pour construire des voitures. Je verrais également des tables dans lesquelles tu indique ce qu'est vraiment une voiture et quelles composantes elle utilise. Enfin on pourrait avoir des tables ou tu stocke les possibilités, des templates quoi?

Voilà, c'est comme cela que je m'imaginais les tables, un listing de tous les éléments par type. Ensuite des tables intermédiaires qui feraient la liaison entre ces tables là.

Alors pourquoi le choix de la BDD? Parce que je vais commencer par une dizaine de voitures, et que j'en ajouterai au fur et à mesure. Et que si je veux changer pour des bateaux ou des camions voire des landaus, je ne devrais "que" changer la base.
Oui mais tu peux utiliser XML/Json? Ben sûrement, mais, ça me semble plus judicieux pour un configurateur de passer par une BDD (de ce que j'en ai compris)
Et SQLite? Il faut que la base soit créée et embarquée avec l'appli, multi-plateforme et pas de lien vers un serveur extérieur. Là encore, ce n'est que le résultat d'une recherche personnelle et pas forcément adéquate.

[Moi 1971]

Donc, maintenant la question est toujours, as-tu vraiment besoin d'un SGBD pour un jeu?
La vraie raison qui doit te pousser à utiliser une base de données c'est le nombre. En dessous d'un seuil c'est inutile.
Si tu prends l'exemple de Forza : 400 voitures, une dizaine de moteurs, une centaine de jantes, 3 types de : freins, amortisseurs, différentiels, volant moteurs,.. Ça fait un paquet de possibilité... Le jeu n'utilise pas de base de données pour gérer tout ça. En revanche, la gestion des joueurs qui se connectent au Xbox Live doit-être pris en charge par un SGBD (pour les raisons qu'a dit NDrew) Chaque mois, Turn10 ajoute des voitures. Il bloque le jeu et force la MAJ pour tout le monde => téléchargement des nouveaux fichiers et basta. C'est plus simple.
Un SGBD ça a un coût. En terme de Temps CPU, temps de connexion, temps de transfert puis interprétation de la requête (hors procédure stockée), exécution puis renvoie des données. Il faut comparer tout ça au temps mis pour ouvrir un fichier en local, le lire et le refermer. Dans la vie de ton jeu, la configuration de la voiture va prendre combien de temps par rapport au reste? Si c'est du genre 10% du temps et le reste du temps la base de données ne sert à rien! l'investissement en vaut-il le coût? En plus, le dev d'un SGBD ça prend du temps. Conception, réalisation, saisie des données...
Maintenant, tout ça ne compte pas si soit tu veux essayer (nouveau challenge) où le SGDB et le serveur sont déjà en service.
Edit !
Maintenant, tout ça ne compte pas si :
1 tu veux essayer (nouveau challenge)
2 le SGDB et le serveur sont déjà en service.