[Débat] Choisir InterBase/Firebird ou Microsoft SQL-SERVER ? - Page 5

Jester · 25/02/2009, 17h08

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.

B.AF · 25/02/2009, 18h08

Ok.
Après tout, c'est du Interbase.

VLDG · 25/02/2009, 23h35

Citation:

Envoyé par Jester

Pour l'instant c'est un peu trop tôt, il faut laisser du temps.

c'est clair, il faut laisser du temps...
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

VLDG · 26/02/2009, 00h22

Citation:

Envoyé par B.AF

Un bon SGBD, c'est avant tout une problèmatique de réponse au volume et au nombre de users.

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 !

Citation:

Envoyé par B.AF

Aujourd'hui, en dehors de considérations de laboratoire, Firebird a chaque fois que je l'ai rencontré en environnement pro, c'était systèmatiquement des problèmes de perfs et de volumes.

c'est intéressant : qui a des problèmes de perfs avec Firebird ?

Citation:

Envoyé par B.AF

Le simple fait que tu juges que Sql Server coûte plus que Firebird prouve que c'est un exercice qui t'es inconnu.

c'est vrai ça : moi qui roule en Porsche, je ne comprends pas pourquoi certain n'ont que des Renault !

Citation:

Envoyé par B.AF

2 - L'administration est très simple (Va administrer un linux vx.xxxxx avec firebird version binaire z.zz.rrr avec la package tt.g qui est patché...Dans une PME...) --> Je ne vois pas où est le coût de formation...Tu devrais peut être ouvrir SQL Manager 2008 une fois..?

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

Citation:

Envoyé par B.AF

8 - Les procédures de backup, c'est aussi biblique (Ca prend approximativement 25 s pour backuper une base...)

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à

Jester · 26/02/2009, 01h17

Citation:

Envoyé par VLDG

en même temps percona ne reste qu'un consultant et patcheur pour MySQL et tous les développements prennent souvent du retard

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.

Vow · 26/02/2009, 14h55

Citation:

Envoyé par B.AF

le meilleur est DE LOIN est sql server, depuis sa version 2005.

Quand je dis le meilleur, c'est ...
- Le support des charges
- Le coût d'administration
- Les coûts de montée en charge
- le coût d'administration OS et Data
- Productivité des équipes
- Outillage impeccable

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

ner0lph · 26/02/2009, 16h21

Citation:

Envoyé par VLDG

SQL Serveur est très bien mais moi je n'en ai pas besoin. Firebird me comble déjà

Je ne fais certes pas avancer le débat, mais je crois que ceci est très important...

Le meilleur SGBD est celui qui vous convient le mieux.

B.AF · 26/02/2009, 16h41

Citation:

Envoyé par Vow

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.

B.AF · 26/02/2009, 16h43

Citation:

Envoyé par ner0lph

Je ne fais certes pas avancer le débat, mais je crois que ceci est très important...

Le meilleur SGBD est celui qui vous convient le mieux.

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

IRAD · 19/03/2009, 15h45

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.

B.AF · 19/03/2009, 20h51

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.

25/02/2009, 17h08	#81
Jester Membre chevronné Inscription : septembre 2003 Messages : 625 Détails du profil Informations forums : Inscription : septembre 2003 Messages : 625 Points : 634 Points : 634	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.
	00

25/02/2009, 18h08	#82
B.AF Membre Expert Inscription : février 2005 Messages : 1 225 Détails du profil Informations forums : Inscription : février 2005 Messages : 1 225 Points : 1 616 Points : 1 616	Ok. Après tout, c'est du Interbase.
	00

19/03/2009, 15h45	#90
IRAD Invité régulier Inscription : juillet 2004 Messages : 24 Détails du profil Informations forums : Inscription : juillet 2004 Messages : 24 Points : 7 Points : 7	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.
	00

19/03/2009, 20h51	#91
B.AF Membre Expert Inscription : février 2005 Messages : 1 225 Détails du profil Informations forums : Inscription : février 2005 Messages : 1 225 Points : 1 616 Points : 1 616	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.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email