Projet : Client Mysql (vs CoreData + Sql Lite)
cargo
Membre
Bonjour,
Je souhaite créer une base de données relationnelle à 3 tables, avec environ 10/15 champs par table qui devra contenir un volume de données assez important (au minimum 10 000 enregistrements par table). Cette base sera situé en local. Eventuellement (mais ceci est très secondaire dans la solution), on pourra y accéder en lecture via internet.
Pour lire et éditer les données, je souhaite développer une app. client Cocoa/Obj-C.
Attention, il ne s'agit pas d'une app. pour gérer la base (type PhpMyAdmin), mais bien d'un client qui agira uniquement sur les datas (sur le contenu et pas sur la structure).
1/ Solution CoreData + Sql Lite
J'ai lu ceci qui démontre que CoreData semble puissant et facile d'utilisation :
http://cocoadevcentral.com/articles/000085.php
Ceci montre que CoreData avait des précurseurs :
http://www.webbotech.com/quickliteoverview.html
J'ai cependant un peu peur de Sql Lite avec un gros volume de données, même si les tests de performances sur le site de Quicklite semblent indiquer que c'est possible.
2/ Solution client-serveur + MySql
J'ai trouvé ce framework qui permet d'interfacer une base MySql avec une app. Cocoa de façon très simple (on peut créer un formulaire sans écrire une seule ligne de code) :
http://www.rtlabs.com/fwork/
Là par contre, je n'ai aucun doute sur la performance de Mysql avec un gros volume de datas.
3/ Solution "Arrête de rêver tu as un niveau zéro pointé en programmation, ce projet est fou, laisse tomber le cocoa et va donc boire un café plutôt..."
(j'ai un très? bon niveau en xhtml/css mais ce n'est pas un langage de programmation comme chacun sait, un peu de php et une solide pratique des bdd complexes sous Access et FileMaker donc Sql ne me fait pas peur du tout)
> Je pense m'orienter vers la solution 2, qu'en pensez-vous ?
(je suis trop tenace pour choisir la 3, en plus je suis attiré par le côté "ludique" de la programmation orienté-objet avec Xtools : j'ai envie de me salir les mains...)
> En ce qui concerne la solution 2 existe-t-il des frameworks open source aussi faciles d'utilisation que celui-là (il est cher) ?
Merci par avance pour vos réponses. Sur ce je retourne à mes tutorials O'Reilly... :crackboom:-
Je souhaite créer une base de données relationnelle à 3 tables, avec environ 10/15 champs par table qui devra contenir un volume de données assez important (au minimum 10 000 enregistrements par table). Cette base sera situé en local. Eventuellement (mais ceci est très secondaire dans la solution), on pourra y accéder en lecture via internet.
Pour lire et éditer les données, je souhaite développer une app. client Cocoa/Obj-C.
Attention, il ne s'agit pas d'une app. pour gérer la base (type PhpMyAdmin), mais bien d'un client qui agira uniquement sur les datas (sur le contenu et pas sur la structure).
1/ Solution CoreData + Sql Lite
J'ai lu ceci qui démontre que CoreData semble puissant et facile d'utilisation :
http://cocoadevcentral.com/articles/000085.php
Ceci montre que CoreData avait des précurseurs :
http://www.webbotech.com/quickliteoverview.html
J'ai cependant un peu peur de Sql Lite avec un gros volume de données, même si les tests de performances sur le site de Quicklite semblent indiquer que c'est possible.
2/ Solution client-serveur + MySql
J'ai trouvé ce framework qui permet d'interfacer une base MySql avec une app. Cocoa de façon très simple (on peut créer un formulaire sans écrire une seule ligne de code) :
http://www.rtlabs.com/fwork/
Là par contre, je n'ai aucun doute sur la performance de Mysql avec un gros volume de datas.
3/ Solution "Arrête de rêver tu as un niveau zéro pointé en programmation, ce projet est fou, laisse tomber le cocoa et va donc boire un café plutôt..."
(j'ai un très? bon niveau en xhtml/css mais ce n'est pas un langage de programmation comme chacun sait, un peu de php et une solide pratique des bdd complexes sous Access et FileMaker donc Sql ne me fait pas peur du tout)
> Je pense m'orienter vers la solution 2, qu'en pensez-vous ?
(je suis trop tenace pour choisir la 3, en plus je suis attiré par le côté "ludique" de la programmation orienté-objet avec Xtools : j'ai envie de me salir les mains...)
> En ce qui concerne la solution 2 existe-t-il des frameworks open source aussi faciles d'utilisation que celui-là (il est cher) ?
Merci par avance pour vos réponses. Sur ce je retourne à mes tutorials O'Reilly... :crackboom:-
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour la 1. même si SQLite sait gérer des tables de la taille dont tu parles (je n'ai aucune idée là dessus), j'aurais tendance à la déconseiller à cause des bindings, que je trouve inappropriés pour un débutant (même si c'est tentant car on arrive à un résultat en suivant un tuto, mais dès qu'on veut en sortir, le risque de patauger est grand).
C'est marrant, instinctivement je l'avais senti comme ça aussi...
Go pour MySql alors !
Ce framework est-il aussi facile d'utilisation que celui dont je parle ? Parce qu'avec http://www.rtlabs.com/fwork/ tout le travail se fait dans Interface Builder quasiment.
PS : Au niveau de l'install des XCodeTools 2.2, ai-je besoin d'installer tous les SDK (OSX SDK et BSD SDK me paraissent suffisant) ? Je suppose que Java et Automator shell scripts update ce n'est pas la peine.
Je souhaite faire une install minimum, juste nécessaire au devlpt de cette app.
EDIT
Doc du Framework de Bru :
- Le framework MYSQLClasses est en fait un " pont " entre le programme Objective-C/cocoa et l'API C du client de connexion vers MySql. De ce fait, l'utilisation du framework ne sera jamais aussi performante que les appels directs à l'API
- Enfin, la gestion des jeux de résultat se fait en mode " chargement complet " : si le programme exécute une requête renvoyant un très grand nombre d'enregistrements, la totalité de ces derniers sont transférés en mémoire et transformés en objet cocoa, ce qui peut pénaliser les performances.
Ca me fait peur tout ça...Est-ce que ça n'utilise pas JDBC (Java bridge) par hasard pour se relier à la base ?
entout cas je te suit dans ta demarche, tout comme toi je doit traviller sur un plugns pour une appli (client sql).
ce plugins doit jaser avec une base de type SQL, je dit bien de type SQL vu que c'est un dialecte.
je n'ai pas eu encore le temp (je realise un geant) et le planning n'est pas encore pointer la dessus, pour en parler en grande lignes, mais sache que CocoaMysql est un bon exemple à voir,c'est une aplli de gestion de serveur SQL.
le code de cette appli peut donc donner une idée de comment causer avec sql server et de récuprer les resultats de tes requêtes.
j'ai regader à cette api dont tu parle elle est res puissante vu quelle estt connecable à tout un tas de bases de données, mais je préfere conseiller l'api utiliser dans CocoaMysql.
le jour où tu tend à travailler de concert sur ce sujet, je suis preneur
Ce qu'il faut comprendre par là , c'est que les méthodes du framework Objective-C appellent les fonctions de l'API C. Cela amène un certain confort au niveau développement, mais pénalise les performances en terme de vitesse car le runtime Objective-C devient alors une couche supplémentaire.
L'API C de MySql est une library dynamique installée par MySql sur le poste client, et qui permet aux programmeurs de gérer une base de donnée dans leurs programmes. Puisque c'est du C, cette API ne travaille qu'avec des pointeurs sur des structures de données. Ce n'est donc pas object.
Le framework permet d'encapsuler, et les données dans des objets cocoa (un char/varchar/blob-texte devient un NSString, etc...), et les appels à l'API via des méthodes de la classe MYSQLConnexion.
Quiconque connait un peu l'Objective-C et cocoa peut donc utiliser ce framework pour créer/gérer ses bases sous MySql.
Afin de rendre la gestion d'une base MySql le plus simple possible, chaque requête (ordre select) qui est envoyée à la base renvoie le résultat dans un tableau NSArray, chaque enregistrement étant dans un NSDictionary contenu dans le tableau.
Si ta requête extrait 10000 enregistrements, ton programme aura donc en mémoire 10000*(nombre de champs dans un enreg) objets. Ceci peut donc poser des problèmes de performance (dû au manque de mémoire qui se posera dans ton appli).
Absolument pas. Le framework utilise la library dynamique (dont le détail est sur le site de MySql.com ici). C'est du C, et c'est rapide.
.
" Core Data should work fine. It's designed to return roughly 30,000 objects per second.
SQLite scales well (tens of millions of rows and such) and is quite reliable. Best Regards,
Scott"
Je suis finalement bien tenté par CoreData...Je réfléchis encore sur mon projet et ses exigences par rapport à sqlite.
Je posterai par la suite une série de liens utiles (coredata, frameworks, comparaisons de sgbd...) et un schéma de mon projet.
Plusieurs postes peuvent-ils attaquer la même base SQLite créée par un managedObjectContext d'une autre application :