Cocoa et bases de données
chaps31
Membre
Pas certains d'être où il faut avec cette question mais je ne sais pas où la mettre.
Je réalise un projet Xcode qui doit utiliser une base de données. Le programme doit ensuite être installé sur des ordis de personnes qui n'ont pas de formation informatique particulière.
J'étais parti sur PostgreSQL (MySQL est payant si on ne veut pas donner son code source et SQLite ne permets pas le multiposte), mais un doute m'étreint peut-on faire tourner sur un ordi un serveur de base de donnée SQL sans personne de qualifié ou mieux vaut-il s'orienter vers autre chose ?
Le problème est que je ne vois pas quelle autres bases de données je peux utiliser avec un projet Cocoa.
Merci de vos lumières.
Je réalise un projet Xcode qui doit utiliser une base de données. Le programme doit ensuite être installé sur des ordis de personnes qui n'ont pas de formation informatique particulière.
J'étais parti sur PostgreSQL (MySQL est payant si on ne veut pas donner son code source et SQLite ne permets pas le multiposte), mais un doute m'étreint peut-on faire tourner sur un ordi un serveur de base de donnée SQL sans personne de qualifié ou mieux vaut-il s'orienter vers autre chose ?
Le problème est que je ne vois pas quelle autres bases de données je peux utiliser avec un projet Cocoa.
Merci de vos lumières.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je pense (suis sûr) que PostgreSQL est le seul moteur de BDD relationnel valable.
Je travaille là dessus depuis pas mal de temps.
J'ai une interface NKD opérationnelle, mais vieille et pas maintenue.
En fait mon problème n'est pas tant l'interface objc-pgsql que cocoa-objc lui-même, dont les réactions semblent faites pour qu'on ne s'en serve pas, sauf dans un clan d'initiés, dont heureusement je ne fais pas partie.
Mais je suis prêt à continuer, d'autant plus qu'on serait plusieurs
bien à toi
Dans le premier cas, il n'est pas difficile d'utiliser un serveur de BDD distant en incluant les entête du SDK du moteur du SGDB. Dans le second cas, il est plus difficile à réaliser et je ne l'ai jamais fait
Autre solutions, attaquer le serveur de BDD via un middleware PHP (un simple page PHP faisant les requête SQL et retournant le résultat formaté en XML)... Cette solution à des avantages :
- C'est le serveur qui supporte la charge de l'exécution des requêtes et la charge mémoire de la DB.
- ça passe à travers les PROXY et sur Internet
- facile à sécuriser via SSL sur Apache.
Le soucis que j'avais c'est qu'il faut un installeur simple et un utilisateur qui comprend le mot postgresql aussi bien que moi je comprend "hytr夝$gt"....
Manquant d'expérience une fois le tout codé je me demande si postgre peut tourner tranquille sur l'ordi sans intervention extérieure, si oui alors j'opte pour postgres même si des soucis restent :
A l'installation il faut modifier le fichier pg_hba.conf pour activer la sécurisation d'accès par mot de passe et pour l'instant je n'ai trouvé aucun moyen simple, pire l'accès au fichier n'est pas ouvert par défaut à l'utilisateur mac os x, uniquement un utilisateur postgres créé automatiquement. Bref bonne galère pour qu'au premier lancement mon appli modifie pg_hba.conf .... C'est ce genre de difficulté et la crainte du besoin impératif de maintenance sur site qui me faisait douter de postgresl...
Mais tu semblent l'utiliser sans problème bofy . Je suppose que tu n'as pas automatisé la modification de pg_hba.conf, la librairie C libpq ne semble avoir rien prévu...
Galère galère le développement d'appli avec base de données avec un mac...
Pourquoi SQLite ne suffirait pas dans ce cas ?
Euh... Moins qu'avec Windows crois moi
- Pas de protection de la base par mot de passe, n'importe qui peut accéder au fichier qui contient la base.
- Les accès concurrentiels : en utilisation courante il peut y en avoir plusieurs (mais moins de 10). Plusieurs ordi reliés en réseau (d'expérience entre 1 et 5) peuvent accéder à la même base. Si une écriture est en cours et qu'une demande d'accès pour écriture arrive si j'ai bien tout compris un verrou empêchera tout accès et le second sera rejeté... Pas terrible...
Oui je préfèrerais SQLite, jamais le projet sera utilisé dans une grosse structure avec pléthores d'ordi en réseau et Postgres ou Mysql sont surement surdimensionnés, mais je ne vois pas de SQLite avec protection de la base contre les curieux ni un moyen de gérer plusieurs demandes d'écriture en même temps, ne serais-ce que 4... Mais peut-être que j'ai mal compris et que les demandes d'écritures sont juste mises en attente et traitées les unes après les autres, auquel cas vu le petit nombre de requête simultanées cela ne devrait pas poser problème.
SQLite est une base "embedded" (embarquée) ; il n'y a pas de connexion réseau à la base, tout est en local.
Alors si tu veux gérer des accès réseau, il faut une interface réseau adéquate (comme gsoap...) dans laquelle tu peux effectivement mettre les requêtes en attente avec un verrou fichier.
Donc, si le serveur n'est pas sur les postes clients, pourquoi se prendre le chou avec l'installateur ?
Edit : gsoap est en GPL, et je ne veux pas dévoiler mon code source... argh
- Plusieurs clients, mais une seule base de donnée (installée sur un serveur à part) commune à tous les clients et à laquelle tous les clients se connectent
- Ou plusieurs clients mais chacun ayant sa propre base de données, installée sur le même ordi donc.
Dans le premier cas, la base de données n'est à installer que sur une machine, ton serveur, et est commune à tous donc oui il faut gérer les accès concurrentiels mais du coup pas besoin de l'installer avec ton soft : toi tu l'installes une fois pour toute sur ton serveur, mais ceux qui utilisent ton client et à qui tu fournis un installeur n'ont pas à s'en soucier, ton installeur n'ayant pas à installer la base de données sur les clients. --> PostgreSQL
Dans le second cas chacun a sa base de données donc oui il faut que ton installeur gère l'installation de la base de données en local sur chaque machine, mais non il n'y a pas à gérer les accès concurrents car il n'y aura pas de notion de réseau, chacun ayant sa propre base qu'il accède de son côté sans toucher à la base des autres. --> SQLite
J'imagine que c'est la première solution qui t'intéresse, une base commune pour tous, donc tu n'as qu'à l'installer sur une machine faisant office de serveur, mais pas à installer la base chez tous les clients, non ? Ou alors j'ai loupé un truc ?
Donc une BDD (nom adresse... des clients, les animaux, les médicaments....), basée sur un ordi. S'il n'y a qu'un ordi plus de problème (SQLite), par contre il faut prévoir plusieurs ordis qui accèderont à la base (exemple : 2 consultations, 1 accueil) et souvent en même temps, donc si j'ai bien compris : postgresql.
Tant que c'est chez moi pas de soucis en effet je m'installe postgres sur le poste principal et ne programme que les accès à la base dans mon projet. Mais en le passant à d'autres (gracieusement au début mais payant par la suite selon la qualité de ma réalisation), il faut donc forcément qu'ils installent une fois le serveur postgresql (pkg tout prêt existe), je m'arrache donc actuellement les cheveux pour intégrer la configuration initiale du serveur postgresql dans mon projet en Cocoa.
De plus il n'y aura personne pour surveiller le serveur, il faut que postgresql soit du velours (SAV par téléphone avec moi).
Donc si j'ai bien tout compris je peux oublier SQLite, Schlum dans un autre post me proposait de résoudre le problème du multiposte mais via gsoap qui est en GPL donc pas possible pour moi, et reste le problème de la sécurisation d'accès à la base qui n'est pas assurée avec SQLite.
Donc point de salut sans Postgresql si je ne me trompe, j'ai cherché d'autres système de base de données, en BSD
Non, gsoap est en multi-licence, dont une "gSOAP Public License" dérivant de la MPL1.1
MPL est entre GPL et BSD... Si on modifie le source de gsoap, on doit rendre public ces modifications ; par contre il n'y a aucune obligation sur le code qui utilise gsoap.
- Mon logiciel Lite inclu SQLite pour la version monoposte
- Mon logiciel Pro avec un serveur MySQL/Postgresql et l'accès via le réseau.
Techniquement, dans le logiciel tu créer une class gérant la connexion a la base de donnée... C'est elle qui, selon la version ira se connecter à la base SQLite ou Postgresql et retournera le résultat. Cela permet dans ton logiciel d'envoyer toujours les mêmes requêtes (et recevoir toujours les mêmes type de réponses) et c'est la class qui "traduit" pour la base utilisé. Cela évite de gérer les deux type de base de partout dans ton programme.
C'est un peux compliqué car il faut gérer deux type de base de donnée dans la même class.
Donc tant que le SQL est "raisonnable", ça paraà®t faisable. Sinon, faut faire des requêtes différentes en fonction du moteur derrière.
Pinus.
Je te l'accorde c'est assez gros comme boulot. Mais il est souvent possible de s'en tirer sans faire des requêtes avec plusieurs "JOIN"
Faire tourner un serveur PostGre c'est assez lourd et contraignant sur un poste " client " qui n'est pas trop fait pour ça.
Je vais me renseigner sur cette fameuse "soupe" :P
SQLite peut gérer des bases lourdes très bien... Le facteur inconnu c'est l'encryption par contre ; jamais utilisé et je ne sais pas si ça ralentit beaucoup :-\\
http://www.hwaci.com/sw/sqlite/prosupport.html#crypto
S'agissant de SQLite, il y a un éditeur qui a développé un serveur au dessus de ce moteur. Serveur qui s'installe en un clic, et qui permet d'encrypter les fichiers de bases de données (et les communications client/serveur) :
http://www.realsoftware.com/products/realsql/index.php
Pas sûr que ça colle à tes besoins, mais c'est peut-être à voir.
Pinus.
Pinus
(Pour mémoire, la conversation portait sur le Client/Serveur avec SQlite, et la protection des données.) C'est donc une des options possibles. Et comme je l'ai dit: c'est pas donné.
Pinus
Je ne m'excite pas, je dis clairement ce que c'est c'est tout
La protection de données est déjà faite en option dans SQLite, et mettre un serveur au dessus de tout ça, ça se fait en 1h avec gSOAP :P
En plus, c'est fait pour travailler avec RealBasic
Ton truc avec gSOAP, ça donne quoi niveau :
- écritures concurrentielles (car c'est bien gentil de mettre un serveur en 1 heure au dessus de SQLite mais si lorsqu'un client écrit, il vérouille toute la base, ton serveur db n'aura de serveur que le nom...)
- Perfs ? SOAP est verbeux et limaceux...
Perso je suis un supporter de PostgreSQL, mais il faut admettre que dans le cadre d'un déploiement auprès de non-professionnels de l'informatique, ça peut (parfois) être délicat...
Pinus.
C'est de toute manière le fonctionnement de SQLite quelque soit la technique utilisée au dessus... À moins que le serveur ne groupe lui même les requêtes ce qui serait dangereux car pourrait bloquer un SELECT.
Vu que les requêtes se comptent en millisecondes, ça ne se voit pas au niveau de quelques utilisateurs.
... et largement suffisant pour ce genre de logiciels
C'est certains qu'avec des requêtes en quelques millisecondes et moins de 10 utilisateurs ça ne doit pas se voir. Tout ça me permettrais de garder une option sur SQLite s'il n'y avait leproblème du cryptage, si à chaque install il faut payer 400 euros pour un soft gratuit ou vendu moins cher... ça ne tiens pas mais merci de l'info.