Discussion :

[vulcan33]

Bonjour, Je me présente: Je me prénomme Jean-Luc;

Ma demande:

Quel choix judicieux et gratuit pour transformer un fichier Excel en base de données autonome; base de gestion d'adhérents.

Besoins:

Consulter la base en recherchant par Nom, voir Prénom pour éviter les doublons(Cas de plusieurs adhérents par famille).
Modifier le contenu de certains champsMise à jour adresse ou N° tel, valider le renouvellement d'adhésion).
Créer une fiche pour un nouvel adhérent.
Supprimer un adhérent en conservant ses infos dans une base "anciens adhérents".
Un menu "Maintenance" pour permettre l'édition et l'impression de la liste des adhérents, la liste de ceux qui ne sont pas à jour de leur cotisation.

Rien , me semble-t-il, de bien compliqué pour des spécialistes de BDD mais une grosse galère pour un novice comme moi.

Peut-être que ce genre de programme existe déjà.

Je cherche une solution gratuite; je ne possèdes pas le pack Office et ne désire pas l'acquérir.
Par contre, je suis en possession de Brilliant Database.

Un grand merci d'avance à toute personne qui saura me conseiller ou m'apporter une aide précieuse.

Jean-Luc

[Michel.Priori]

Bonsoir Jean Luc,

C'est pas évident de choisir le bon forum quand on est novice ; Décision SGBD c'est le raccourcis de SGBD décisionnelle, une sous branche des SGBD.
En tous les cas c'est comme ça que je l'ai compris

Des SGBD open source il en existe essentiellement 3 :
-PostgreSQL
-MariaDB
-MySQL
MySQL à été racheté par ORACLE et le fondateur historique à fait un fork pour continuer l'aventure : MariaDB.
PostgreSQL appartient à la communauté, c'est plus sûr, pas de rachat en vue

Sinon les "grands" éditeurs offrent une version bridée mais largement suffisante pour un projet comme le votre.
On trouvera ORACLE EXPRESS (XE) et SQL server express.

En dehors de ces "grands" noms il existe au moins une bonne centaine de SGBD différents.
Désolé pour ceux que je n'ai pas nommé.

Or le problème est que vous allez être déçu si vous vous attendez à pouvoir faire des formulaires et des états directement avec ces produits ; ils ne font pas ça.

Les SGBD ne s'occupent que de stocker et rendre la donnée.
Le langage consacré est le SQL.
On ne peut pas dessiner un carré bleu (ou rouge) avec du SQL.
La couche "présentation" est traitée par un autre outil qui faudra interfacer avec la base.
Par contre un SGBD est capable de tenir le choc face à de la montée en charge (volume de donnée > 100Go et plusieurs 10aines d'utilisateurs) tout en assurant sécurité et continuité.
Chaque produit ayant ces avantages bien sûr.

Je ne connais pas "brillant database" mais s'il propose grosso modo ce qu'Access ou 4D proposent, je vous dirais de rester dessus, à condition qu'il y ait une bonne doc et une communauté active.

A tout hasard des produits comme open office ou libre office ne conviennent pas ?

[vulcan33]

Merci Michel pour votre réponse.

Je ne suis peut-être pas au bon endroit pour effectuer ma demande.

Même pour les forums, je suis novice.

En fait, je cherche juste une possibilité de gestion des mises à jour d'une centaine d'adhérents avec des garde-fous pour éviter toute mauvaise action sur un fichier excel; d'ou la gestion de cette liste en utilisant des formulaires.

Je souhaite quelque chose de simple à créer sans devoir utiliser une usine à gaz.

Brilliant Database semble être un bon logiciel mais comme tout logiciel, pour un novice ce n'est pas évident et l'anglais ne facilite pas les choses.

Merci encore d'avoir pris la peine de me répondre.

JLuc

[escartefigue]

Bonjour,

Si l'application concernée est mono-utilisateur, pour quelques centaines de fiches, excel suffit largement.
Le contrôles de doublons peuvent se faire facilement au moyen de fonctions excel, voire du VBA le cas échéant.

L'intérêt d'un SGBD c'est surtout pour gérer les accès concurrents (multi-utilisateur et/ou multi-thread) et pour une volumétrie conséquente.

[StringBuilder]

Comment faites vous pour utiliser Excel sans avoir Office ?

Bref, le choix logique depuis Excel, c'est Access. L'avantage d'Access c'est qu'il dispose de tous les assistants nécessaires pour transformer des fichiers Excel existants en base de données sans effort ni compétence de modélisation.
Le second avantage d'Access, c'est que si la base de données évolue fortement (non plus 100 adhérents, mais 1 milliard, vous voilà à la tête du parti communiste chinois) vous pouvez aisément déverser vos données dans une base de données digne de ce nom (SQL Server par exemple) tout en continuant à utiliser Access pour gérer l'interface utilisateur.

Après, Libre Office et consors sont censés pouvoir faire plus ou moins la même chose, mais je n'ai jamais essayé.

Reste ensuite la solution de trouver un copain ou stagiaire qui vous fasse un programme/site qui permette de faire ce que vous souhaitez à moindre coût.

[vulcan33]

Merci pour vos réponses.

Je ne cherche pas quelque chose de compliqué.

J'ai ce ficher Excel avec des données. Je possède la liste des adhérents sous forme de listing papier.

Je cherche donc à créer une base qui me permette de Consulter, Modifier ou Créer des fiches en utilisant des formulaires.

Je désirerai surtout utiliser un programme autonome, d'ou l'idée d'une base de données mais je ne connais rien en programmation.

Gratuit, de préférence. Je ne souhaite pas acheter Excel ou Access.

Cela concerne une centaine de fiches tout au plus. C'est vraiment une petite asso, d'ou le manque de moyens.

Merci à vous pour vos pistes de choix.

[StringBuilder]

Donc le plus simple est de partir sur Libre Office qui contient un équivalent gratuit à Access.

Car si je ne m'abuse, Brillant Database n'apporte probablement rien ou presque (mise à part des ennuis : pilote ODBC absent, incomplet, etc. assistants d'import/export de données absents/incomplet, etc.) et surtout c'est payant.

Reste la solution de demander à quelqu'un de l'asso ou un proche de faire un petit programme : il pourra alors utiliser une base SQLite par exemple.

[vulcan33]

Bonjour,
Suite à vos informations, je me suis tourné vers mySQL sous wamp64.
J'ai réussi à créer ma base mais, après avoir essayé, a peu près tout ce qui existe (du moins tout ce qui ne fonctionne pas), je n'arrive pas à importer mes données.
Transformation des données en CSV, en TXT etc; je me retrouve avec une base vide ou des données de certaines colonnes à 0.
La seule réussite concerne la dénomination des colonnes.
Auriez-vous des astuces car il semblerait que ce soit un problème récurrent bien connu.
Merci d'avance.

JLuc

[SQLpro]

Mauvais choix... MySQL est le pire des SGBDR !

A +

[openlowcode]

Que lui reprochez-vous ? moi, j'en suis plutôt content pour de petites bases de données.

[StringBuilder]

Que lui reprochez-vous ? moi, j'en suis plutôt content pour de petites bases de données.

Comme Access, c'est super pour des petites bases de données.

Pour le reste, MySQL est moins gratuit que SQL Server Express par exemple, et ne supporte pas le quart de ce qu'on peut faire avec SQL Server (y compris Express).

Même si les pires lacunes et inepties de MySQL sont corrigée/améliorées dans les dernières versions, il n'en reste pas moins l'un des plus mauvais élèves parmi tout les SGBDR (déjà à commencer qu'il n'est pas capable de garantir l'intégrité des données dans toutes les situations... un simple backup alors que la base est en cours d'utilisation, et les données sont corrompues !)

[SQLpro]

Que lui reprochez-vous ? moi, j'en suis plutôt content pour de petites bases de données.

1) ce n'est pas un SGBD relationnel
2) pas de catalogue système => pertes d'objet possible (table par exemple) sans aucun avertissement
3) une gestion débile des transactions (validation automatique de toutes les transactions utilisateurs dans certaines circonstances et sans avertissement)
4) pas de gestion de schéma SQL (et confusion sur la notion de bases et de schéma)
5) résultats de certains calculs faux
6) pas de message d'erreur lors de certaines opérations illégales
7) gestion des collations très limitées
8) utilisation imbécile de l'UTF8 qui fait enfler les bases (trois fois plus volumineuses que les produits concurrents)
9) sauvegarde non consistante ou bloquante
10) chiffrement passoire (plusieurs utilisateurs ont été condamnés par la RGPD à de fortes amendes...)
11) aucune possibilité de stocker des documents électronique sous le contrôle du SGBDR
12) nombre impressionnant de bugs (73 817)
13) correction des bugs plus que laxiste. Exemple 14 ans pour corriger le bug 199 sur l'auto incrément....
14) 279 failles de sécurité découverte en 7 ans (pour information, avec SQL Server pour la même période c'est 8... soit 35 fois plus malgré que le code SQL Server soit d'un volume de 37 fois celui de MySQL, donc un rapport de bug à la ligne de code de 1 300 fois plus de bugs... une paille !)
15) des performances lamentables....

je suis en train d'écrire un article sur le sujet qui devrait être publié sur developpez.com. En voici a conclusion :

"
Depuis longtemps, MySQL fait croire qu’il sait faire tout ce que font les grands SGBDR sans que les DSI n’aient réellement testées ses capacités opérationnelles, et le choisissent parfois pour des solutions critiques. Or la plupart des fonctions avancées de MySQL sont, soient farcies de nombreux bugs – certains monstrueux – soient dotées de performances totalement inacceptables lors de la montée en charge ou pire, de failles de sécurité incompatibles avec certaines réglementations, ou plus grave encore d’erreurs conduisant à détruire les données ou restituer des résultats faux...
Mais comme l’époque n’est plus à l’étude, mais à faire vite et merdique, on laisse passer dans l’entreprise des solutions qui sont de véritables bombes a retardement.
"

A +

[Waldar]

Depuis longtemps, MySQL fait croire qu’il sait faire tout ce que font les grands SGBDR sans que les DSI n’aient réellement testées ses capacités opérationnelles, et le choisissent parfois pour des solutions critiques. Or la plupart des fonctions avancées de MySQL sont, soient farcies de nombreux bugs – certains monstrueux – soient dotées de performances totalement inacceptables lors de la montée en charge ou pire, de failles de sécurité incompatibles avec certaines réglementations, ou plus grave encore d’erreurs conduisant à détruire les données ou restituer des résultats faux...
Mais comme l’époque n’est plus à l’étude, mais à faire vite et merdique, on laisse passer dans l’entreprise des solutions qui sont de véritables bombes a retardement.

Je digresse un peu, mais tu remplaces MySQL par Hadoop et c'est tout aussi valide !