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
Oracle Database
PostgreSQL
MySQL
MariaDB
Microsoft SQL Server/Azure SQL Database
Firebird
Interbase
DB2
SAP Adaptive Server
SQLite
Microsoft Access
Autre
Pas d'avis
Je comprends mieux comme ça, d'ailleurs, je ne parlais pas non plus de changement de version. J'avais surtout compris que dans certains cas d'urgence certains faisaient des modifications directement dans l'étape 2 sans passer par l'étape 1 (ce qui me semble assez irresponsable car ce n'est pas le rôle de la pré-prod).
Salut Pierre GIRARD.
Tout ça pour dire que dans le monde bancaire (sous gros système IBM), les interventions sont lourdes et fastidieuses.
Nous ne pouvons pas faire de backup comme on le veut. Seul l'exploitation peut se le permettre et sous certaines conditions.
Déjà que sur 24 heures, c'est extrêmement rare, alors sur 15 jours, faut pas rêver.
Tout ça pour répondre à aserf, qui certainement dans son environnement, peut se permettre de travailler ainsi.
Il ne s'agit pas de compétences mise en cause, mais juste une organisation de travail.
@+
Oui une mauvaise expérience avec WebSphere Portal WCMEnvoyé par Artemus24
salut
je trouve oracle super
Je trouve Mysql pas super.
- N'évolue pas
- Comportement incompréhensible si on commence à faire du l'équivalent pl-sql.
- Selon le niveau de complexité du code, les résultats sont parfois non logique et aléatoire.
Mais soit, peut importe, le plus gros reproche que je fais c'est que ça n'évolue plus et je me pose la question sur l'avenir de Mysql.
Actuellement, je bosse sur PostGresql, ça semble bien plus performant mais pour ceux qui ont bossé que sur Mysql le passage va être un peut rude.
D'autant pus que PG vient de faire un bond en avant important en ajoutant le parallélisme des requêtes à la dernière version....
A +
John Peter
Le meilleur est celui qui répond à une demande dans un bref délais et dans un domaine.
Ce qui détermine sa valeur devant ces utilisateurs
Dans ce cas là c'est incontestablement SQL Server :Le meilleur est celui qui répond à une demande dans un bref délais et dans un domaine
Ce qui détermine sa valeur devant ces utilisateurs
1) SGBD OLTP (relationnel)
2) SGBD OLAP (décionnel)
3) embarqué (localdb)
4) gratuit (express)
5) diverses version entreprise (web, standard, Enterprise)
6) cloud (Azure)
7) multiplateforme : Windows, Linux !
A +
Pour ma part :
==> SQL Server
+ DB Mirroring est excellent, dommage que ca soit abandonné par Microsoft qui veux migrer tout le mode sur AlwaysOne (dispo que sur l'edition Enterprise et qui a ma connaissance demande du multicast ou broadcast donc pas usable sur Google Cloud par exemple)
+ SSMS est une de meilleurs GUI que je connaisse (Mais quelques bugs dans la version 2016, lié au mirroring)
+ La gestion des fichiers (MDF, LDF) est bien foutu, c'est facile de déplacer les BDD ou d'avoir une configuration un peu custom (Logs sur un disque, bases sur un autre, etc.)
+ Connection strings et client qui gère directement le failover sur le DB mirroring (pas besoin de "proxy/pooler")
+ Intégration avec les outils MSFT (VS, ADDS, .NET, etc.)
- Prix, Ca reste assez cher, c'est dommage qu'il y ai pas de solution de H.A même basique sur l'edition web, du coup ca augment énormément le prix si on veut au moins de la H.A)
- J'ai eu quelques surprise comme des procédure stockés qui ne se retrouvais plus compilé aprés un failover (Besoin d'un sp_recompile alors qu'il y a compilation automatique...)
- Dommage que le backup du DB mirroring ne puisse pas être accessible en lecture, ou permettre plusieurs backups avec different paramètres ( Par exemple un backup async over un VPN pour le reporting, etc.)
==> PostgreSQL
+ Replication "SIMPLE" facile a configurer depuis les dernières versions (Quasiment automatique with "pg_basebackup -R")
+ PL/Python, PL/* pratiques
+ Bonne communauté
- Si vous voulez du failover automatique (A la mirroring + witness), bonne chance. Quoi qu'il y a des projets comme Stolon qui ont beaucoup de potentiels et sont plus simple que tout faire manuellement (PGSQL + REPMGR + PGPOOL2) : https://github.com/sorintlab/stolon
+ PgAdmin est "OK" (Mais loins de SSMS)
On va bientôt migrer toute notre production sur PostgreSQL, on verra bien ce que ca donnera (Raison de réduction des couts), la seule chose qui me fait peur c'est d'avoir une H.A aussi bien foutu que avec du DB Mirroring.
Tu te trompes, AlwaysOn est une surcouche du Mirroring pour lequel la couche système cluster assure le heartbeat et possède l'avantage d'avoir de multiples noeuds répliqués : jusqu'à 3 réplicas synchrones et 8 asynchrone.
En sus c'est disponible en version Standard depuis 2016 SP1 mais avec quelques limites...Tu peut faire du Log Shipping !- Prix, Ca reste assez cher, c'est dommage qu'il y ai pas de solution de H.A même basique sur l'edition web, du coup ca augment énormément le prix si on veut au moins de la H.A)
A +
Bonjour à tous,
Pour ma part je travaille sur db2 Zos V10, luw (9.5, 9.7, 10.1 et 10.5) et du Postgresql (9.2, 9.4 et 9.5) sous linux ...
Autre point, facile de faire communiquer les 2 DB2 luw et zOs !
Evidement une préférence pour DB2 mais je suis tombé dedans tout petit
Bonne soirée
Je rejoins certains de vos commentaires
- les très mauvaises bases ne survivent pas (mais font parfois long à crever !)
- il y a des bases pour des besoins spécifiques et à des coûts spécifiques : le tout est de trouver la bonne base pour les bons besoins. Le choix d'un moteur ne peut donc se faire sur le critère unique de la norme, mais sur une kyrielle de facteurs.... dont celui, non des moindres, de la connaissance de l'outil et des compétences à disposition pour l'utiliser à bon escient.
- une mauvaise modélisation rend n'importe quel moteur impropre à la consommation
- les compétences des développeurs / DBA ont un réel impact sur le ressenti d'une base
- c'est un milieu où les "guerres de clocher" influent sur le jugement critique...
Pour ma part, est c'est purement subjectif
- j'apprécie Oracle pour son large éventail de fonctionnalités et le fait qu'un DBA puisse agir sur quantité de paramètres... et ses outils de monitoring (Grid control)
- j'apprécie MS-SQL pour son interface simple et conviviale, et son architecture
- j'apprécie Sybase ASE pour ses performances et .... son histoire... (mais là, c'est personnel
)
- je n'aime pas DB2-UDB pour son administration et son instabilité... mais j'apprécie le respect de la norme au niveau du langage.
- j'aime bien Informix pour sa robustesse, mais il devient anecdotique...
- j'aime bien MySQL pour ses différents moyens de stockage (souvent si mal utilisés), sa facilité d'administration, et... depuis qu'Oracle tend à le rapprocher des comportements de la norme. Il reste le moteur le plus présent chez les providers internet...
- j'aime bien Postgresql qui allie les avantages de MySQL et la puissance d'un pseudo-PL-SQL pour le développement.
- j'aime même bien MS-Access pour sa convivialité nullement égalée pour des micro-développements
Le comparatif est toujours en attente de vos commentaires / critiques... du moment qu'ils sont étayés...
Rien ne sert de m'envoyer des commentaires dithyrambiques sur une base... je crois être rompu aux boniments des éditeurs...
Essayez de remonter les points positifs ET NEGATIFS des bases que vous connaissez...
Merci d'avance
Fabien Celaia aka fadace
Salut Fadace.
Ce n'est pas si évident que cela car on peut très bien imaginer que le produit va servir pour un service dans un besoin ponctuel.
Or le succès faisant, il est détourné de son contexte premier et vient à ne plus du tout répondre au besoin ponctuel.
Le dimensionnement est un point important pour définir le choix d'un SGBDR.
Mais personne ne peut présager de l'évolution d'un produit sur le long terme.
Il peut très bien finir à la poubelle, cinq ans après, ou être encore présent cinquante après.
De même, il peut être surdimensionné et ne jamais atteindre sa pleine vitesse de croisière, tel qu'il a été prévu, dès le départ.
La norme est le langage commun à toutes les SGBD relationnels, enfin cela devrait l'être. Le non respect de la norme n'est pas une cause de rejet du SGBDR.
Sinon, la plupart des SGBDR auraient disparu depuis fort longtemps.
Ce qui fait le succès de tel ou tel SGBDR est la facilité de sa mise en oeuvre.
Je ne suis pas convaincu de cette vision. S'il suffisait qu'un SGBDR soit enseigné à l'école pour qu'il ait un succès, cela se saurait depuis long temps.
Donc non, ce ne sont pas les compétences mises à disposition sur le marché du travail qui font le succès d'un SGBDR.
Ce sont ceux qui sont à l'initiative de ces projets qui choisissent les SGBDR, et non ceux qui vont par la suite les utiliser.
Il y a un coté psychologique sur la préférence pour tel ou tel SGBDR qui ne peut pas être appréhender par des études sur ce qui pourrait être le meilleur SGBDR.
Pour diverses raisons, le SGBDR qui serait le plus utilisé au monde pourrait être le plus pourri et non celui qui serait plébiscité par les utilisateurs.
Entièrement d'accord ! Sauf qu'une base de données vit et évolue au fil du temps.
Il existe des dégradations de la modélisation, uniquement pour répondre à des besoins de performances.
Je ne suis pas d'accord, car un développeur n'a aucun initiative à prendre.
Ils sont là pour répondre à un cahier des charges. Si celui-ci est mal conçu, ce n'est pas la faute du développeur.
Inversement, on ne va pas embaucher un débutant quand on a besoin d'une personne expérimentée.
Mais là, c'est une autre question, dépendant des choix de l'équipe dirigeante.
Pourquoi ? Habitez-vous à Clochemerle ?
En résumé, vous aimez tous les SGBDR sur lesquels vous avez travaillé.
Pour ma part, je mets en premier deux SGBD qui sont :
--> BULL gros système avec IDS II.
--> IBM gros système avec DB2 Z/OS.
Pourquoi ? Peut-être parce que ce sont les premiers sur lesquels j'ai travaillé et appris.
Et comme je viens du monde bancaire et gros système, je retrouve toute la rigueur que l'on nous demandait dans la conception et la mise en oeuvre.
Dans le monde de la mini ou micro-informatique, il y pléthore SGBDR qui ont tous des avantages et des inconvénients et où aucun ne se distingue vraiment des autres.
Il y a parfois de bonnes idées comme les CTE (Common Table Expression) qui peuvent se justifier dans des contextes particuliers, mais dans l'ensemble, j'aurai préféré que l'on simplifie et perfectionne le moteur sur des notions élémentaires.
A trop vouloir enrichir avec de nouvelles fonctionnalités, on complexifie les SGBDR à outrance, sans que cela soit un apport pour l'administrateur.
Je pense que l'on fait un mauvais usage de ces SGBDR où, comme je le constate, on demande de résoudre des problèmes de présentation ou procédurale alors que ce n'est pas leur but.
@+
C'est ce que font tous les éditeurs depuis nombre d'années, mais les opérations élémentaires sont déjà extrêmement optimisées.
Bien sûr, on trouvera toujours un meilleur algorithme à implémenter, mais le chemin parcouru me semble gigantesque.
Vous avez fait trop de banque. Les bases de données ne sont pas faites pour leurs administrateurs, elles sont faites pour répondre à des besoins métiers.
Plus ou moins OK concernant la présentation, mais le procédural je ne vous suis pas.
Quand on cherche à résoudre un problème de données - quand je dis problème, ça peut être de la création de nouvelles données à partir de l'existant - c'est quand même le SGBD le mieux placé pour effectuer ces opérations.
Et enrichir les fonctionnalités des SGBD permet de résoudre plus de problèmes d'une part et de mieux en mieux d'autre part - typiquement les CTEs récursives, les fonctions de fenêtrage, et les langages procéduraux inclus (PL/SQL, T-SQL, PL/pgSQL & co).
Salut Waldar.
Je ne suis pas aussi convaincu que vous sur les opérations élémentaires. Je le constate avec MySql où il y a encore beaucoup de chose à améliorer afin d'obtenir un temps de réponse acceptable.
Je parle du gros système où on utilise les SGBDR que dans la fonctionnalité de base, à savoir extraire des données.
Je n'ai pratiquement jamais vu des requêtes en jointure sur plus de trois tables.
Alors que dans le monde de la micro-informatique, il est fréquent de faire des jointures sur un maximum de tables.
Le besoin métier est défini par la fonctionnelle et c'est la modélisation qui va s'adapter au SGBDR.
D'où justement la difficulté du passage du logique au physique et des aspects performances !
Je ne serai pas aussi categorique que vous sur ce point, sinon on n'aurait pas besoin d'une expertise dans ce métier qui serait alors accessible par n'importe qui.
Et qui intervient dans les SGBDR quand vous avez un gros problème ? Je vous le donne en mille : le DBA ou quand c'est trop compliqué, l'expert !
Le rôle d'un SGBDR est de faire de l'extraction de données et uniquement cela.
Si la modélisation est correcte, vous n'avez pas besoin de faire du procédural au niveau du SGBDR.
Et n'oubliez pas que vous n'êtes pas seul à accéder à votre base de données.
Si tout le monde lance sa procédure dans le SGBDR, je ne vous explique pas les temps de réponses déplorable que vous risquer d'obtenir.
Le seul cas où je considère que le procédural est faisable, c'est :
--> dans des batch de nuit pour préparer la journée du lendemain (domaine bancaire)
--> pour faire de la maintenance.
Pas nécessairement. Vous ne voyez que l'aspect faisabilité dans votre façon de raisonner. Et que faites vous de la performance ?
Imaginez que votre approche dure deux heures par une procédure dans votre SGBDR.
Et que le même travail fait autrement, sans passer par le SGBDR, dure cinq minutes.
A votre avis, quelle est l'approche qu'il faut préconiser ?
@+
Salut
A contre-partie un SGBDR trop orienté ADMINISTRATEUR aura très peu d'adeptes dans le monde des développeurs et des cursus de formation (car difficile à prendre en main). Conséquence moins de visibilité. CF firebird qui n'a pas encore une interface graphique propre.
Mois par exemple, j'ai adopté PostgreSQL en très grand partie à cause de PgAdmin et j'utilise JAMAIS le client en ligne de commande.
Les éditeurs doivent attirer d'avantage les développeurs que les administrateurs (AMHA). Il faut alors résoudre coté serveur autant que possible des besoins standards plutôt que de lancer "C'est pas la fonction du SGBDR!"
@+
Il faut les deux, un SGBDR sans administrateur, le jour où il y a un vrai pétard, bonjour les dégâts si il faut repartir d'une sauvegarde qui fasse perdre plusieurs jours (ou plus ... semaine, mois) de saisie. Surtout au moment où le SI va aller voir les développeurs pour leur demander de rétablir la situation en vitesse. La fonction d'un administrateur, c'est de surveiller la base en permanence et prévenir les problèmes plutôt qu'intervenir en pompier.
Et pour Firebird, j'ai FlameRobin qui me convient très bien comme interface graphique.
Considérez vous que SAP soit du monde de la micro ? Pour autant les requêtes dans SAP ont un nombre considérable de table en jointure...Non, c'est aussi de faire du traitement de données ![...]
Le rôle d'un SGBDR est de faire de l'extraction de données et uniquement cela.Pour des raisons de performances, le procédural intégré au serveur n'a rien à voir avec ce que vous pourriez faire côté applicatif ! Pensez même que maintenant les bon SGBDR travaillent en "in memory" et avec des procédures compilées nativement en C... Exemple : MS SQL Server https://msdn.microsoft.com/en-us/library/dn249342.aspxSi la modélisation est correcte, vous n'avez pas besoin de faire du procédural au niveau du SGBDR.Justement, plus les traitement iront vite, plus les données seront disponible tôt, et meilleures sera la concurrence, car le temps de traiter les données elles sont verrouillées en lecture ou en écriture suivante la nature du traitement.
Et n'oubliez pas que vous n'êtes pas seul à accéder à votre base de données.Je ne sais pas quel est votre expérience à ce sujet, mais dans Sybase (qui a inventé le concept de Persistent Stored Module) et SQL Server (et dans Oracle aussi) plus vous utilisez de procédures stockées et mieux ça marche. Il est même fortement conseillé de n'utiliser que cela et d'éviter les requêtes "ad hoc"...Si tout le monde lance sa procédure dans le SGBDR, je ne vous explique pas les temps de réponses déplorable que vous risquer d'obtenir.Ne seriez vous pas né au siècle dernier au temps du boulier ???
Le seul cas où je considère que le procédural est faisable, c'est :
--> dans des batch de nuit pour préparer la journée du lendemain (domaine bancaire)
--> pour faire de la maintenance.
C'est souvent le contraire... Mais dans ce cas vous auriez parfaitement raison...
[...]
Imaginez que votre approche dure deux heures par une procédure dans votre SGBDR.
Et que le même travail fait autrement, sans passer par le SGBDR, dure cinq minutes.
A +
Salut SQLPRO.
Vu ce que vous dites, je ne peux qu'être d'accord avec vous.
Mais j'ai déjà constaté que l'on utilise le procédural coté serveur parce que plus souple à l'usage que de le faire coté applicatif. Je parle ici, de ce que j'ai vu sous mysql.
Ce n'est pas uniquement une question de performance comme vous semblez l'indiquer mais la façon de répartir équitablement les traitements entre le serveur et l'application.
Or il arrive que le traitement qui se fait sur le serveur aurait dû se faire dans l'application.
C'est juste une constatation que je fait, mais il existe toujours le contre-exemple.
Tout est relatif ! Et je ne raisonne pas comme vous. Je pense qu'il faut laisser le serveur disponible, en y passant le moins de temps possible.
Et je reste convaincu qu'une application qui travaille en mémoire avec fichier séquentiel, tourne plus rapidement que le même traitement dans une procédure stockée.
Quand je faisais du développement sous gros système, il nous était interdit d'utiliser les déclencheurs, les procédures stockées, les fonctions car on nous disait à l'époque que cela était de gros consommateurs de performance.
Quand nous faisions un accès à la base de données, c'est fréquemment au travers d'une requête existante, dans un module cobol que nous nous partagions au travers de plusieurs applications.
Je pense que vous oubliez que dans les grands comptes où je travaillais, nous avions des contraintes de développements, justifiées parfois, mais pas tout le temps que nous ne pouvions pas remettre en cause.
Nos programmes étaient validés afin de savoir si nous respections les normes de développements.
Sans cela, nous ne pouvions pas les migrer vers l'exploitation et de surcroît vers la production.
Dans le monde de la micro-informatique, vous avez beaucoup plus de libertés dans le développement que dans le monde du gros système.
Même si ces recommandations ne sont pas toujours justifiés, nous devions impérativement nous y plier.
Il se peut aussi que depuis cette époque, certains comportement ont changé, mais je n'y crois pas trop.
La raison à cela repose essentiellement sur la culture d'entreprise et la maintenance (même façon de développer en suivant une méthodologie).
Je sais très bien que ce sont des pratiques qui remontent avant mon départ à la retraite.
Et dans mes dernières missions, je faisais de l'administration DB2 coté exploitation, et plus du tout du développement coté études.
Je me rappelle d'un cas particulier où le balayage de la totalité de la table sous DB2 sous forme procédurale, prenait beaucoup plus de temps que de décharger la table sous la forme d'un fichier séquentiel, de faire le traitement et de recharger la table.
Je ne me souviens plus trop si la table en question était ou pas adapté à ce genre de traitement. Ni d'ailleurs du traitement en question, vu que cela est fort ancien pour moi.
Mais il était nécessaire de faire, durant la nuit, un batch de traitement, pour répondre à des traitements quotidiens.
Depuis cette époque, il y a eu de gros efforts qui ont été faite coté performance et ce dont je me souviens, peu très bien ne plus exister.
Donc oui, parfois, j'ai encore de vieille réaction qui ne sont plus du tout justifié aujourd'hui.
@+
Cela pouvait être vrai avant dans certains cas particuliers. Ce n'est plus vrai du tout dans pratiquement aucun cas de figure avec le "In Memory" dont le principe est de ne plus faire aucun accès disque et de transformer les procédures stockées en programme exécutable natif en C.... Difficile de rivaliser !
A +
Répondre avec citation
Partager