Discussion :

[Toto ZEHERO]

Bonjour à tous,
ne maîtrisant pas (encore) du tout le sujet, je cherche à savoir quel logiciel/outil utiliser pour gérer une base de données, adaptée à mon cas (ci-dessous).

Mon contexte : pour les besoins d'une application Android basée sur un événement sportif, je voudrais pouvoir afficher (selon les clics de l'utilisateur) :

- la composition d'une équipe (photos joueurs et leurs noms) et ses stats complètes,

- après clic sur l'un des joueurs, sa photo et ses stats personnelles

Je dispose d'un espace de stockage sur un site web où je stockerai ma base de données et à laquelle mon application accédera (vraisemblablement par l'intermédiaire d'une page PHP "tampon").

J'ai bien lu à droite/à gauche de nombreux avis et questions-réponses, mais le débat me paraît interminable pour pouvoir faire un choix clair et précis, quand il n'est pas carrément trop technique pour moi (pour l'instant). Pouvez-vous m'aider à orienter mon choix vers une ou plusieurs solutions viables et sur laquelle je pourrai me former de façon limpide de façon à être autonome ?

Merci par avance !!

[StringBuilder]

Déjà, voyez ce que vous porpose votre hébergeur.

99% de chances qu'il ne propose que MySQL ou MariaDB, étant donné que vous êtes orienté hébergement PHP.

Pour les 1% restants, SQL Server (y compris Express) et PostgreSQL sont deux alternatives où vous avez tout à y gagner. Dans les offres low cost, je n'ai pas trop d'idée d'autre SGBD. Mais voyez déjà ce que porpose votre hébergeur, à mon avis il a choisi pour vous

[rudib]

Bonjour,

qu'appelez-vous "ses stats" ? Des informations que vous agrégez vous-même ou des informations déjà alimentées ? Votre modèle semble peu structuré et une base de données NoSQL orientée documents pourrait convenir, comme MongoDB.
Pour les applications Android, et si vous pensez qu'elle risque d'avoir du succès, il existe des solutions en cloud qui peuvent vous simplifier la vie, par exemple DynamoDB sur AWS ou https://cloud.google.com/datastore/ ou https://www.clusterpoint.com/ ou https://parse.com/

[Toto ZEHERO]

Déjà, voyez ce que vous porpose votre hébergeur.

99% de chances qu'il ne propose que MySQL ou MariaDB, étant donné que vous êtes orienté hébergement PHP.

Pour les 1% restants, SQL Server (y compris Express) et PostgreSQL sont deux alternatives où vous avez tout à y gagner. Dans les offres low cost, je n'ai pas trop d'idée d'autre SGBD. Mais voyez déjà ce que porpose votre hébergeur, à mon avis il a choisi pour vous

Désolé pour le retard de ma réponse, je cours de partout en ce moment..
Merci pour votre réponse. Effectivement, mon hébergeur propose des bases MySQL ou PgSQL (à vrai dire, je ne connais pas la différence entre les deux puisque je n'avais jamais encore entendu parler du dernier).
Je rebondis justement sur votre message (pour commencer à apprendre quelque chose sur les BDD) : lorsqu'on parle de PHP lié aux bases de données, c'est nécessairement MySQL ou MariaDB ?

Et pourquoi dites-vous "tout à y gagner" en parlant de SQL Server et PostgreSQL ? Présentent-ils des avantages que n'a pas MySQL par exemple ?

[Toto ZEHERO]

Bonjour,

qu'appelez-vous "ses stats" ? Des informations que vous agrégez vous-même ou des informations déjà alimentées ? Votre modèle semble peu structuré et une base de données NoSQL orientée documents pourrait convenir, comme MongoDB.
Pour les applications Android, et si vous pensez qu'elle risque d'avoir du succès, il existe des solutions en cloud qui peuvent vous simplifier la vie, par exemple DynamoDB sur AWS ou https://cloud.google.com/datastore/ ou https://www.clusterpoint.com/ ou https://parse.com/

Bonsoir,
Merci pour votre réponse.

Les "stats" dont je parle seront a priori la plupart du temps effectivement des informations que je rajouterai moi-même pendant ou après chaque match, mais il se peut que j'en récupère également "alimentées" comme vous dites.

J'ai beaucoup de questions à présent...

• Pour mon information, pourquoi dites-vous que mon modèle semble peu structuré ?

• Et pour bien comprendre, une base orientée documents type MongoDB, si j'ai bien lu dans les quelques recherches que j'ai faites, permet de gérer un volume très important de données en ajoutant, modifiant ou supprimant seulement certains champs dans un document, c'est bien ça ?

• Quel est l'avantage (/les avantages) de passer par une solution en cloud plutôt que par mes bases de données hébergées ?

[StringBuilder]

Bonjour,

Même si vous faites un almanach complet des jeux olympiques depuis l'antiquité grèque, je doute que même avec des stats complètes (tous les essais, record hors compétition, homologués ou non) vous arriviez à un "gros" volume en terme de base de données (à savoir plusieurs tera).

Là, je vois à la louche une base de données qui ne dépassera certainement pas les quelques dizaines de méga, voir centaines si vous collez les photos directement dedans.

Donc, en restant objectif, c'est "rien" à gérer, même pour le piètre Access qui n'est pas du tout fait pour ça.

Sinon, pour répondre aux questions :
- Tout à y gagner en évitant MySQL, ça veut dire que vous allez éviter le pire des outils jamais créés dans le monde de l'informatique. Vendu comme un SGBDR, il est tout au plus un mauvais SGBD. Il ne respecte aucun standard, est truffé de bugs, et quand il fait semblant de respecter les normes, il a un comportement anormal (par exemple, incrémentation en lot d'une clé unique, qui n'est pas gérée sous forme ensembliste). Bref, une daube intersidérale.
- MySQL est culturellement associé à PHP. Pour la simple et bonne raison que l'essort de PHP s'est fait sur des serveurs hébergeant MySQL (qui a le mérite d'être un des premiers SGBD simples à administrer distribuable gratuitement -sous conditions ceci dit-), et notamment son célèbre "bundle" nommé PHPMyAdmin. Cependant, PHP peut parfaitement travailler avec d'autres SGBD. La plupart des SGBDR du marché à vrai dire. SQL Server, Oracle, PostgreSQL, DB2, par exemple.
- PostgreSQL, à défaut d'être un "bon choix", est votre meilleure alternative face à MySQL. Il respecte bien mieux la norme, et se comporte comme un vrai SGBDR. Il a cependant quelques lacunes comparé à d'autres SGBDR "de luxe" que sont SQL Server ou Oracle par exemple.
- L'intérêt d'un cloud par rapport à du serveur hébergé (dédié ou non) c'est avant tout la haute dispo (pas la peine de se soucier des sauvegardes ni de la maintenance) ainsi que des coûts maîtrisés : on ne paie que pour ce qu'on consomme, ce qui est très pratique quand on a des activités en dent de scie (par exemple, pour des jeux olympiques, on a un gris pic d'activité pendant 2 mois tous les 4 ans, et tout le reste du temps, c'est idiot de payer le même tarif alors qu'on ne sollicite pas le serveur... Les solutions cloud sont basés à la fois sur le volume hébergé et sur le trafic, donc on y gagne. On y gagne aussi sur le dimensionnement et son évolution : vous commencez par un abonnement à 1 euro par mois et une base de 10 Mo avec 4 pèlerins qui y accèdent dans le mois. Et deux ans plus tard, vous avez 800 To de données et des millions de connexions par heure. Avec une solution cloud, tout est transparent (y'a juste la facture qui monte). En contre-partie, on ne fait pas tout ce qu'on veut sur un cloud : le SGBD est imposé, sa version aussi, les modules complémentaires aussi, etc. (on peut avoir le choix, mais jamais autant que sur un serveur dédié).

[rudib]

D'accord and StringBuilder sur le sujet du cloud : vous n'avez pas à vous soucier de l'infrastructure, et vous pouvez bénéficier d'un environnement et d'une facturation élastique, même s'il faut faire attention de maîtriser les coûts. Il est facile sur AWS de choisir des options payantes et d'avoir des surprises à la prochaine facture. Faites vos calculs avant.

Le raisonnement n'est pas "MongoDB c'est génial, j'ai lu un article, on peut faire du Big Data et c'est très rapide". D'ailleurs ce n'est pas un raisonnement. Choisissez MongoDB si votre modèle de données correspond à un document, hiérarchisé, qui va être le plus souvent manipulé comme un document complet. Pour mieux comprendre, regardez la notion d'agrégat en DDD (Domain Driven Design). On appelle ça des données semi-structurées : des données bien typées (une date, un montant) mélangées avec des données plus larges et moins "typables", du texte un peu long par exemple. Exemples de données semi-structurées : un contrat, une lettre de convocation, ... peut-être un événement sportif ?

"permet de gérer un volume très important de données en ajoutant, modifiant ou supprimant seulement certains champs dans un document", c'est la définition de tout SGBD, qu'il soit relationnel ou pas. MongoDB permet moins de modifier, supprimer seulement certains champs dans une données, parce qu'on a plus tendance à récupérer tout un document, à la modifier et à le réécrire atomiquement que dans un SGBDR où les colonnes sont accessibles directement.

Les solutions cloud que j'ai mentionnées sont du DAAS (Database as a Service), et ça peut très bien faire votre affaire.

[Toto ZEHERO]

Je vous remercie tous les deux pour vos réponses précieuses.

Je vais cependant essayer de me former aux BDD en suivant un ou plusieurs tutoriels afin de mieux cerner ce que vous évoquez, car cela reste encore trop "abstrait" (à défaut d'un autre adjectif) pour moi pour l'instant. J'avais abordé le sql avec SQL Management Studio "en courant d'air" il y a quelques mois, qu'en pensez-vous ? Est-ce une bonne solution pour (re)démarrer et acquérir des bases solides ?

J'aimerais par ailleurs avoir un éclairage sur MySQL : il est vrai que le terme MySQL lui-même est super connu, mais j'entends/je lis très souvent aussi des critiques qui vont dans le sens de vos commentaires. Pouvez-vous me fournir un exemple concret (et qui parlerait directement à un profane tel que moi) de la différence entre MySQL et SQL Server ?

Et pour votre commentaire sur MySQL :

il a un comportement anormal (par exemple, incrémentation en lot d'une clé unique, qui n'est pas gérée sous forme ensembliste).

Pouvez-vous m'expliquer en mots clairs ce qu'il fait (ce qu'il faudrait ?)?

Merci beaucoup pour votre aide.

[SQLpro]

Pouvez-vous me fournir un exemple concret (et qui parlerait directement à un profane tel que moi) de la différence entre MySQL et SQL Server ?

Pas de comparaison possible :
1) SQL Server est une suite d'outils comprenant :
1.1 - un SGBD relationnel (SQL Server)
1.2 - un SGBD décisionnel (SSAS)
1.2 - les outils de forage des données (data mining)
1.3 - un ETL (SSIS)
1.4 - un outil de reporting (SSRS)
1.5 - des outils pour aller vers le Big Data (connecteurs hadoop)
MySQL lui ne compte que le moteur relationnel...
Donc à ce match : 5 contre 1

2) niveau de SQL :
MySQL en est resté à la norme Sql de 1992 (et encore, certaines fonctionnalité de cette norme ne sont toujours pas implémentées, comme les schémas SQL !). La dernière norme SQL est celle de 2011 ! Entre temps il y a eu la norme 1999, 2003, 2008...
Ce que MySQL ne permet pas et que tous les autres SGBDR ont :
2.1 - les schémas SQL (CREATE SCHEMA...)
2.2 - les requêtes CTE (common table expression)
2.3 - les requêtes récursives (via les CTE)
2.4 - les fonctions de fenêtrage (clause OVER, et notamment fonction RANK, DENSE_RANK... indispensable vue votre activité !)
Ce que MySQL ne permet pas et que tous les SGBDR sauf PostGreSQL proposent :
2.5 - Temporal Tables (norme SQL 2011)
Ce que permet SQL Server ey qu'aucun autre SGBDR n'a :
2.6 - Index couvrant (cllause INCLUDE)
La encore 6 manques cruciaux !

3) Fonctionnalités
Lisez mon article à ce sujet : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux


4) Performances
Lisez cet article : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
Faites simplement la comparaisons d'un simple SELECT COUN(*) sur une grosse table dans la plupart des SGBDR... Vous comprendrez !
https://www.periscopedata.com/blog/c...nd-oracle.html
Par exemple MySQL n'a pas de cache de plan de requête ce qui oblige à les recalculer systématiquement et pour une requête complexe c'est très couteux. En revanche il a un cache des résultats, mais pour une base transactionnelle cela ne sert a rien et encombre le cache avec des données inutiles...
De la même façon, l'optimiseur est très limité et en pratique interdit l’utilisation des vues et les requêtes avec beaucoup de jointures...
Bref inexploitable de manière professionnelle !


Après cela si vous choisissez MySQL, c'est que vous êtes maso !

Pour information, notre collègue Nicolas Souquet alias Elsuket vient de prendre le poste de DBA d'un grand éditeur de logiciel français ayant des clients américain, et dont les applications était sous MySQL... Compte tenu des problèmes de performances (médiocre à catastrophiques) et de l'instabilité du SGBD (MySQL has gone away....) ils sont passé sur SQL Server et n'ont plus aucun problème !

A +

[Toto ZEHERO]

Bon, j'ai bien compris que MySQL est le diable, l'horreur, et tout ce que vous voudrez d'autre(s) pour un utilisateur confirmé... (j'en comprends en tout cas les grandes lignes..)
Cependant, en tant que novice total dans les BDD et après avoir parcouru vos liens fort intéressants, et m'être abreuvé de termes pro. que seul un utilisateur confirmé tel que vous peut suivre, j'en reviens à mes questions initiales :

J'avais abordé le sql avec SQL Management Studio "en courant d'air" il y a quelques mois, qu'en pensez-vous ? Est-ce une bonne solution pour (re)démarrer et acquérir des bases solides ?

[elsuket]

SQL Server Management Studio étant l'outil livré avec SQL Server, c'est l'outil de prédiclection pour le développement sous SQL Server.

@++

[Toto ZEHERO]

SQL Server Management Studio étant l'outil livré avec SQL Server, c'est l'outil de prédiclection pour le développement sous SQL Server.

@++

Oui... jusque là, c'est indéniable, fort logique..

MAIS : est-ce que débuter avec SQL Server (et donc en utilisant dans mon exemple SQL Management Studio) est une bonne solution, OU PAS pour démarrer et commencer à comprendre quelque chose aux bases de données, et acquérir les bons réflexes ?

SINON (dans le cas du OU PAS), quel est le plus sage ? Démarrer avec une autre solution pour SQL et laquelle ? avec peut-être du NoSQL et lequel ? autre chose ??

[SQLpro]

Oui... jusque là, c'est indéniable, fort logique..

MAIS : est-ce que débuter avec SQL Server (et donc en utilisant dans mon exemple SQL Management Studio) est une bonne solution, OU PAS pour démarrer et commencer à comprendre quelque chose aux bases de données, et acquérir les bons réflexes ?

SINON (dans le cas du OU PAS), quel est le plus sage ? Démarrer avec une autre solution pour SQL et laquelle ? avec peut-être du NoSQL et lequel ? autre chose ??

Avec PostGreSQL, c'est l'un des SGBDR les plus proche de la norme SQL. Les plus éloignés étant Oracle et MySQL.
Mais SQL Server est plus riche fonctionnellement que PostGreSQL qui d'ailleurs, soufre de quelques tares dont la plus importante est qu'il n'est pas tout à fait relationnel !
A me lire : http://blog.developpez.com/sqlpro/p1...bd_relationn_1
http://blog.developpez.com/sqlpro/p1...-de-postgresql

A +

[fsmrel]

Bonjour,

est-ce que débuter avec SQL Server (et donc en utilisant dans mon exemple SQL Management Studio) est une bonne solution, OU PAS pour démarrer et commencer à comprendre quelque chose aux bases de données, et acquérir les bons réflexes ?

Après plus de 40 ans passés à chahuter des régiments de SGBD en tous genres, je dis que débuter avec SQL Server est une bonne solution pour les bases de données SQL.

Sinon, du point de vue de la théorie relationnelle, voyez les projets orientés D.

[Toto ZEHERO]

Avec PostGreSQL, c'est l'un des SGBDR les plus proche de la norme SQL. Les plus éloignés étant Oracle et MySQL.
Mais SQL Server est plus riche fonctionnellement que PostGreSQL qui d'ailleurs, soufre de quelques tares dont la plus importante est qu'il n'est pas tout à fait relationnel !
A me lire : http://blog.developpez.com/sqlpro/p1...bd_relationn_1
http://blog.developpez.com/sqlpro/p1...-de-postgresql

A +

Très bien, merci bien pour votre réponse.

[Toto ZEHERO]

Bonjour,
Après plus de 40 ans passés à chahuter des régiments de SGBD en tous genres, je dis que débuter avec SQL Server est une bonne solution pour les bases de données SQL.
Sinon, du point de vue de la théorie relationnelle, voyez les projets orientés D.

Ok, merci bien pour votre réponse et votre lien.


Et merci(à nouveau) à tous pour votre aide précieuse et votre temps !!