# Cocoa + MySQL



## HommeCocoa (31 Décembre 2005)

Bonsoir,

Est-il possible "d'attaquer" une base de donnée MySQL avec des composants Cocoa?

Merci d'avance
Bonne soirée!

David


----------



## molgow (31 Décembre 2005)

Une piste c'est le driver ODBC pour MySQL :
http://dev.mysql.com/downloads/connector/odbc/3.51.html

Ça te permet d'accéder à ta base de données depuis n'importe quel programme en C (ou Obj-C évidemment).


----------



## HommeCocoa (31 Décembre 2005)

merci!


----------



## sekaijin (2 Janvier 2006)

plutôt un framwork natif
http://kinks.ultralab.ac.uk/projects/cocoa/frameworks/mysql/


----------



## cretinoïde (2 Janvier 2006)

sekaijin a dit:
			
		

> plutôt un framwork natif
> http://kinks.ultralab.ac.uk/projects/cocoa/frameworks/mysql/



oui surtout pas d'ODBC !

Il faut passer par un wrapper obj-c comme mentionné plus haut...


----------



## molgow (3 Janvier 2006)

cretinoïde a dit:
			
		

> oui surtout pas d'ODBC !



Pourquoi ?!


----------



## cretinoïde (3 Janvier 2006)

molgow a dit:
			
		

> Pourquoi ?!



parce que ca n'a pas d'utilité dans le cas précis. 

S'il s'agit d'atteindre une base MySQL en local (appli cocoa et serveur sql sur la meme machine, un wrapper obj-c est parfait ---> plus rapide, plus souple, moins dépendant d'un logiciel intermediaire odbc). S'il s'agit d'atteindre un seveur MySQL hebergée sur le web, de simples requetes peuvent suffirent (requetes passées via les méthodes http de cocoa).

Le driver ODBC n'a rien à voir à priori dans l'affaire. 

Maintenant s'il s'agit de faire du local pur, je déconseille MySQL et autre SGBD "lourd". SQLite ira tres bien et est en plus encapsulable.


----------



## HommeCocoa (4 Janvier 2006)

En faite, le but était aussi de pouvoir atteindre des base MySQL non locale


----------



## cretinoïde (4 Janvier 2006)

HommeCocoa a dit:
			
		

> En faite, le but était aussi de pouvoir atteindre des base MySQL non locale



alors passer des requetes http suffira !

ODBC sert surtout dans cas ou 2 SBGB ne sachant pas se parler en ont justement besoin.


----------



## molgow (4 Janvier 2006)

Je comprends pas ce que t'appelles "requêtes http" ?! 

Si je dois faire des requêtes sur une base de données depuis un programme Java (je fais surtout du Java), je passe par un driver JDBC. Alors avec Objective-C, on va devoir passer via un driver ODBC. Non ?


----------



## cretinoïde (4 Janvier 2006)

molgow a dit:
			
		

> Je comprends pas ce que t'appelles "requêtes http" ?!
> 
> Si je dois faire des requêtes sur une base de données depuis un programme Java (je fais surtout du Java), je passe par un driver JDBC. Alors avec Objective-C, on va devoir passer via un driver ODBC. Non ?



Ce que je veux dire c'est que rien ne t'empeche de passer des arguments à partir de ton appli Cocoa vers des scripts du genre "php .com/script.php?var=toto" distants grace à la méthode cocoa NSURL (threadable à souhait en plus).

C'est habile, rapide et efficace dans bien des cas.

Ensuite le wrapper peut etre necessaire dans d'autres cas plus complexes.

mais je n'ai jamais eu besoin d'ODBC pour acceder à une base mysql ou sqllite à partir d'une app Cocoa.


----------



## molgow (5 Janvier 2006)

Hmm... alors là je vois plusieurs problèmes !

- ça ne s'applique qu'à une base de données qui tourne sur un serveur web. 
- il faut avoir un script (php par exemple) sur le serveur web distant pour accéder à la base de données. Donc la simplicité que tu pourrais gagner sur ton client, tu la perds un peu en devant programmer un script.
- la sécurité ! Tu fais comment pour l'authentification ? Tu peux pas faire ça par une requête GET en toute sécurité, c'est pas génial. Ou du moins, la sécurité sera problématique.
- le traitement du résultat (si tu veux faire un select), tu obtiendras un simple fichier texte ? Ensuite il faudra le lire et l'interpréter (avec tous les problèmes que ça peut poser) pour obtenir les informations qui t'intéresses vraiment.

La méthode que tu préconises, je l'ai utilisée qu'une fois dans ma vie, et c'était vraiment parce qu'on pouvait pas faire autrement puisque j'accédais à des informations distantes depuis une appli J2ME sur téléphone portable...

Donc je réitère mon conseil pour HommeCocoa : utiliser le driver ODBC ou un framework comme celui proposé par sekaijin.


----------



## cretinoïde (5 Janvier 2006)

molgow a dit:
			
		

> Hmm... alors là je vois plusieurs problèmes !
> 
> - ça ne s'applique qu'à une base de données qui tourne sur un serveur web.
> - il faut avoir un script (php par exemple) sur le serveur web distant pour accéder à la base de données. Donc la simplicité que tu pourrais gagner sur ton client, tu la perds un peu en devant programmer un script.
> ...



Je reitere le mien aussi : un wrapper (appelle le framework si tu veux) obj-c idéal pour les bases en local (voir le lien donné par nicky) ou la commande d'un script distant via NSUrl. Un driver ODBC j'en vois pas la pertinence.


----------



## sekaijin (7 Janvier 2006)

quand je parle de framework je parle d'outils qui vont plus loin qu'un simple wrapping

mais une classe ObjC qui permet la connexion directe et native à MySQL quelle fasse partie d'un frame work ou non sera plus efficace qu'un passage par un médiateur comme ODBC.

ODBC est intéressant si tu veux que ton application se connecte à diverse base de données. 
en clair dans ce cas ton application se connecte à une source de donnée ODBC peu importe que ce soit d MySQL PostGreSQL Sybase Oracle ou MSSQL et je ne sais quoi.

dans ce cas ce qui prime c'est d'utiliser une base de donnée et de laisser l'utilisateur choisir sa source de donnée

si par contre ton appli doit utiliser une ou plusieurs moteur de base connus  une connexion directe et native est à privilégier. elle t'offrira de la performance en plus mais aussi est surtout des fonctions que tu n'aurais en ODBC. 

contrairement à mon collègue je dirais que le fais que la base soit locale ou distante n'entre pas en jeu dans cette affaire.
les avantage d'une connexion native reste valable où que soit le serveur. la seule difficulté que cela implique mais c'est pareil avec ODBC c'est qu'il faut que le serveur soit visible de l'application par le réseau. donc de potentiel pb avec les firewall

Passer par http est une solution peu orthodoxe mais qui à le mérite de passer sur internet sans difficulté. si par exemple ton fournisseur d'accès internet t'offre un hébergement avec MySQL mais que tu n'a le droit d'attaquer ta base que depuis ton serveur http tu ne pourras pas établir de connexion ni en natif ni en ODBC

la solution installer un script php qui sert de proxy et qui t'ouvre la voie vers ta base.

tu peux chercher sur internet EMS MyManager EMS PgManager ce sont des outils windows qui permettent de manipuler une base de donné sous windows. il propose en standard un script php à mettre sur le serveur pour faire ce genre de proxy
ensuite tout se passe comme si EMS Manager était connecté directement à la base (au pris d'un certain ralentissement)

coté programmation faire un myquery() dans le langage de son choix revient à ouvrir une url (celle du proxy) et de lui fournir les info sur ce qu'il y a à faire. le script retourne le résultat qu'il faut interprété et mettre à disposition

A+JYT


----------



## cretinoïde (8 Janvier 2006)

sekaijin a dit:
			
		

> quand je parle de framework je parle d'outils qui vont plus loin qu'un simple wrapping
> (...)


Merci d'avoir complété mon explication. 

Quand je parlais d'une base non-locale, je parlais d'une base over the web d''ou la méthode NSURL.


----------



## molgow (8 Janvier 2006)

sekaijin a dit:
			
		

> si par contre ton appli doit utiliser une ou plusieurs moteur de base connus  une connexion directe et native est à privilégier. elle t'offrira de la performance en plus mais aussi est surtout des fonctions que tu n'aurais en ODBC.



Sauf les rares cas où les performances sont vraiment importantes, ODBC reste quand même une solution qui privilégie la réutilisabilité du code. Même si la base de donnée est de type MySQL, rien n'indique que demain un changement d'architecture n'interviendra pas. 

Et puis, connexion directe ne veut pas forcément dire plus rapide. Tout dépend de l'implémentation. Dernièrement, pour un logiciel nécessitant une très grande rapidité j'ai passé par JDBC car il me fallait 30 sec pour charger les données au lieu de 5 min avec un framework se connectant directement à la base.


----------



## sekaijin (12 Janvier 2006)

molgow a dit:
			
		

> Sauf les rares cas où les performances sont vraiment importantes, ODBC reste quand même une solution qui privilégie la réutilisabilité du code. Même si la base de donnée est de type MySQL, rien n'indique que demain un changement d'architecture n'interviendra pas.
> 
> Et puis, connexion directe ne veut pas forcément dire plus rapide. Tout dépend de l'implémentation. Dernièrement, pour un logiciel nécessitant une très grande rapidité j'ai passé par JDBC car il me fallait 30 sec pour charger les données au lieu de 5 min avec un framework se connectant directement à la base.



OUI mieux vaux JDBC ou ODBC qu'un mauvais framework

pour ce qui est de la manipulation des données Il faut toujours se poser la question

lorsqu'on doit accéder à des fonctionnalité spécifique d'un moteur de base de donnée 
ODBC ou JDBC ne savent pas faire.

Donc le choix ne se pose que si l'application fait des accès au données (query)

si l'accès à la base se fait pour savoir quel est l'espace mémoire occupé ou pour connaître la liste des poste connecté au serveur ce n'est plus possible.

pour les perfs une interface native est toujours plus rapide.
si le framwork qui est bâtit sur cette interface est lent ça ne change rien à ce fait. il faut soit améliorer le framework en question soit en prendre un autre.

A+JYT


----------

