Discussion :

[pluche52]

Bonjour,

Je cherche a réaliser une petite base de données avec KEXI, pour une liste d'objets. Ces objets peuvent ou non se retrouver dans un ou plusieurs catalogues (table catalogue_objet faisant lien).
Je souhaiterais faire sortir tous les objets, même ceux ne se trouvant pas dans un catalogue. Mais je suis coincé.
J'avais pensé à quelque chose du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM objet LEFT OUTER JOIN catalogue_objet
ON objet.id = catalogue_objet.objet_id

D'ailleurs KEXI refuse ma requête en renvoyant que LEFT est un mot clé réservé....

Merci pour votre aide !

[StringBuilder]

Bonjour,

KEXI et SQLite sont deux produits différents.

De ce qu'on trouve sur Google, KEXI est un ersatz de Microsoft Acces, et même pas celui d'Open Office.

Dans la mesure où Access est un très mauvais SGBD, très incomplet, et que généralement, Open Office c'est un mauvais copier/coller d'environ 5% de ce que permet de faire Microsoft Office, et par conséquent, KEXI qui est lui-même un mauvais copier/coller incomplet d'Open Office Base, j'ai envie de tirer des conclusions hâtives : KEXI ne supporte pas d'autres jointures que "INNER JOIN" ou alors peut-être avec une syntaxe ultra merdique propriétaire.

En tout cas, votre syntaxe est correcte, et le message d'erreur indique un non support du standard SQL... 89. Super, 30 ans de retard...

[pluche52]

Bonjour,

Merci pour votre réponse. Je cherche à faire une petite base de données pour concentrer moins d'une centaines de lignes et 4 ou 5 tables. Que me conseillez-vous de choisir ? Je n'aime pas Access non plus et je trouve d'ailleurs que c'est sortir la grosse artillerie pour peu....

Merci par avance de vos lumières

[StringBuilder]

Si vous n'aimez pas Access, vous pouvez partir sur du Open Office Base (que je ne connais pas du tout ceci dit).

Sinon, un petit SGBD comme SQLite fera probablement l'affaire.
Par contre, le souci d'un "vrai" SGBD, c'est qu'il n'y a pas d'interface graphique intégrée : donc si vous pouvez pouvoir créer des écrans de consultation, mise à jour, interrogation, vous serez obligé de programmer avec un autre outils.

[Waldar]

Dans la mesure où Access est un très mauvais SGBD, très incomplet,

Je nuance un peu en disant qu'Access est un SGBD fichier Windows avec les limites que ça induit, mais est un bon produit facile à prendre en main.
Pour le besoin de pluche52 ça me paraît bien adapté.

[pluche52]

Bonjour,

Merci pour votre aide. Que vaut le SGBD de Libre Office par rapport à celui d'Access ? Tant que faire se peut, car cette base de données sera utilisée par plusieurs personnes au sein de plusieurs sociétés, j'aimerais me détourner des logiciels propriétaires.

Merci d'avance

[escartefigue]

il existe des versions de MS SQL server gratuites, ce sera toujours bien mieux que ACCESS

[StringBuilder]

En règle générale, Libre Office (ou Open Office) sont un cran en dessous de Microsoft Office sur la plupart des fonctionnalités.
Access étant probablement le logiciel Office le plus complexe, il est très fort probable que leurs équivalent "open" ou "libre" soient assez drastiquement limités.

Après, selon vos besoins, vous ne serez pas forcément confronté à ces limitations. Après tout, les outils Writer ou Calc sont parfaitement utilisables malgré leurs limitations.

Par contre, je ne suis pas trop d'accord quand vous dites que vous voulez faire du libre pour ne pas rencontrer de soucis chez vos clients.

Si vous faites votre base de données avec Libre Office, elle ne sera utilisable qu'avec Libre Office.
Si vous la faite avec Open Office, elle ne sera utilisable qu'avec Open Office (car même si Libre Office est un fork d'Open Office, il est fort probable que tout ne soit pas compatible).

En tout cas, si vous avez des clients qui utilisent déjà une suite Office, ils seront probablement réticents à en utiliser une seconde, même gratuite, pour pouvoir utiliser votre base.

Sinon, escartefigue, je pense que pluche52 cherche un programme intégré afin de créer sa base de donnée et l'interface associée sans ce lancer dans la programmation.

-- Edit : jusqu'en version 2010, Access permettait de "compiler" une application "*.mdb" afin de l'exécuter sans nécessiter Access sur le PC, mais ce la n'existe plus. Il existe cependant "Access Runtime" qui, à défait de permettre la création d'un *.exe, semble permettre d'utiliser une base *.accdb sans nécessiter Access installé sur le PC… à voir
https://support.office.com/en-us/art...6-91cbe3ea09c9

Attention par contre niveau licences à mon avis c'est pas libre d'utilisation, se renseigner sur les contextes possibles d'utilisation.

[pluche52]

Bonsoir,

Merci pour votre aide et conseils. Le but est de pouvoir effectivement exporter cette petite base chez quelques particuliers pour un usage propre. Ce que je cherche est effectivement une solution intégrée car pour une base de données de moins de 100 lignes, ce serait à mon sens écraser une mouche avec un marteau de faire du sur-mesure. Je trouve qu'Access et LibreOffice Base sont déjà pour des projets plus gros.
J'ai trouvé NSbase qui semble convenir à mon projet. l'implémentation de la base s'est bien passée et je cherche maintenant à dépatouiller avec LUA, que je ne connais pas du tout...

Encore merci pour vos lumières !

[StringBuilder]

Honnêtement, restez "standard".
Access ou Libre Office, même s'ils semblent un peu surdimensionnés de prime abord, ont de nombreux avantages :
- On trouve l'un ou l'autre sur presque chaque PC dans le monde
- Énormément de gens savent se servir de l'un ou de l'autre, voir des deux
- Même si on est loin d'un support exemplaire du SQL, et que ce ne sont pas des SGBD-R, ils restent des outils suffisamment répandus pour qu'on puisse traiter leurs spécificités comme des "standards".
- La pérennité de l'un comme de l'autre est assurée pour les prochaines années
- Il existe des outils et beaucoup de gens ont des expérience de migration à partir de ces outils vers de "vrais" SGBD si un jour votre programme devait grossir

NSbase, jamais entendu parlé (pas plus que KEXI), et il y a fort à parier que :
- La communauté soit de l'ordre de quelques milliers d'utilisateurs répartis dans le monde
- Que chaque spécificité sera à découvrir en mode "demerden Sie sich" sans aucun espoir de support ni de la part de l'éditeur ni de la part de la communauté
- La plupart de ces produits n'existera plus dans 5 ans
- Le jour où votre besoin évolue et que vous avez besoin de plus gros ou plus complexe… vous n'aurez rien pour vous aider à migrer vos données (ressaisir à la main des centaines de milliers de lignes de données, croyez-moi, ça n'a rien d'amusant)

Bref, le conseil du jour : si vous ne souhaitez pas faire du sur-mesure, alors calquez-vous à un "standard" répandu : vous aurez plus de chances d'avoir un outil qui répond à vos besoins actuels et futurs, et plus de chance d'obtenir de l'aide