Je pense que pour les SGBD, il faut toujours voir des cas d'applications. Un SGBD ne peut pas être la meilleure solution dans tous les cas.
Les produits MS ont l'énorme avantage d'avoir de bons outils/interfaces avec.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Je pense que pour les SGBD, il faut toujours voir des cas d'applications. Un SGBD ne peut pas être la meilleure solution dans tous les cas.
Les produits MS ont l'énorme avantage d'avoir de bons outils/interfaces avec.
Ok.
Après tout, c'est du Interbase.
c'est clair, il faut laisser du temps...Envoyé par Jester
J'ai eu l'occasion de discuter avec un gars de MySQL AB qui était venu nous faire une formation il y a 3 ans (il nous parlait de Falcon comme une révolution avant la fin de l'année...) et actuellement je ne sais pas qui utilise Falcon en production...
j'ai vu un slide de percona et il parle de 2010 - 2015 ? pour la version 6.0
http://www.percona.com/files//presen...ensql-2008.pdf
en même temps percona ne reste qu'un consultant et patcheur pour MySQL et tous les développements prennent souvent du retard
oui ici on compare Firebird et SQL Serveur : c'est a dire la ou ils sont comparables... autrement on comparerai peut être SQL serveur à Oracle ou DB2 !
c'est intéressant : qui a des problèmes de perfs avec Firebird ?
c'est vrai ça : moi qui roule en Porsche, je ne comprends pas pourquoi certain n'ont que des Renault !
La devise de Jim Starkey qui a été à l'origine d'Interbase était en gros "pas d'administration" alors que tu prennes cet exemple me fait doucement rire. Tu ne compares pas SQL Serveur à Oracle
c'est vrai que les backups sous Firebird sont beaucoup moins réguliés (en fait ça dépend de la taille de la base...)
SQL Serveur est très bien mais moi je n'en ai pas besoin. Firebird me comble déjà
Il faut voir qu'une partie du business de percona c'est de faire des patch pour innodb et qu'ensuite ils assurent le support de ces mysql patchés. Pour eux falcon ce sera de la concurrence. Si leur plan est de continuer dans cette voie, autant que MySQL 6.0 prenne du retard. Ainsi ils auront le temps de rendre innodb compétitif. Mais oui, la version 6 n'est pas pour demain.en même temps percona ne reste qu'un consultant et patcheur pour MySQL et tous les développements prennent souvent du retard
Tu oublies de dire que par rapport à la version 2000, il est surtout bien plus lourd et gourmand en ressources
Personnellement SQL Server 2000 me convient toujours, j'ai moins de m**** dessus avec mes développements.
Quant à FireBird, je n'ai jamais vraiment trop testé... mais je n'ai pas spécialement vu non plus des problèmes de perfs
Je ne fais certes pas avancer le débat, mais je crois que ceci est très important...SQL Serveur est très bien mais moi je n'en ai pas besoin. Firebird me comble déjà
Le meilleur SGBD est celui qui vous convient le mieux.
Tu oublies de dire que par rapport à la version 2000, il est surtout bien plus lourd et gourmand en ressources
Personnellement SQL Server 2000 me convient toujours, j'ai moins de m**** dessus avec mes développements.
Quant à FireBird, je n'ai jamais vraiment trop testé... mais je n'ai pas spécialement vu non plus des problèmes de perfs
Oui enfin faut relativiser aussi entre 2000 et 2005, le coût du hardware est devenu ridicule.
C'est pas choquant et même plutôt rassurant que le produit exploite les ressources de son temps.
a 4000 € euro OS inclus+Serveur SQL tu as des serveurs déjà très performants sur un couple win/intel.
Le coût de stockage est devenu lui aussi devenu dérisoire depuis.
Je veux dire dans le même ordre d'idée, Linux, windows, solaris sont tous devenus plus lours.
Non. Le meilleur c'est celui :
Qui rempli les conditions à J
Donne des certitudes sur sa capacité à les gérer à J+x avec des performances identiques sur une loi d'augmentation définie
Qui rempli les conditions de sécurité nécessaire
Qui a le coût unitaire de transaction le plus faible
Qui pose le moins problème d'intégration SI
Qui coûte le moins cher en administration
Bonjour à tous
J'ai essayer de suivre ce débat en lisant les différents points de vue depuis le début. Mais très sincèrement j'en sort encore plus confus qu'au début.
Je crois qu'il faut prendre en compte le fait que celui qui cherche à se lancer ne connais pas forcement toutes le subtilités autour des SGBD.
Supposez un programmeur ou analyste programmeur qui n'a pas forcement des compétences de DBA et qui pourtant doit se lancer dans le développement d'un application de gestion. Je ne suis pas certain que le terme "grosses volumétrie" signifie quelque chose pour lui. Il sera plus familier à des termes comme "nombre de table", "nombre d'enregistrement dans une table", "nombre d'utilisateurs simultanément connectés". Pour quelqu'un qui s'y connait un peu, on pourra lui parler de trigger, de procédures stockées, de fonctions spécifiques etc.
Je sais qu'il y a le comparatif des SGBD ici http://fadace.developpez.com/sgbdcmp/, mais je ne crois pas que ce soit suffisant pour prendre une décision.
Est-il possible de prendre des critères simples mais importants dans le choix (un débutant ne sait pas toujours ce qui peut lui poser de problème plus tard) pour orienter les préférences? Ne pas se baser sur une seule fonction qu'on ne retrouve pas.
Dans cette logique, en dehors des différents avis que nous pouvons formuler, tu devrais alors plutôt essayer d'avoir une vision 'dépôt'.
C'est à dire de créer un schéma pouvant indifféremment être exploité sous firebird ou sql server.
--> utiliser uniquement les fonctionnalités communes et identiques, des types simples.
Ce serait le plus cohérent.
Tu pourras toujours parès coup vérifier quel moteur te semble le plus approprié avec les données, les charges, ou pourquoi pas garder les deux.
Répondre avec citation
Partager