Débat postgresql vs MySQL

Citation:

---

Envoyé par SQLpro

http://www.tpc.org/tpcc/results/tpcc_results.asp
http://www.tpc.org/tpce/results/tpce...ic_results=yes

---

Je ne sais quoi penser d'un tel benchmark (comme souvent du reste) dans la mesure où les SGBD sont différents mais aussi les machines qui les hébergent et les O/S qui les animent.
Il en va sans doute de même avec la qualité et quantité de RAM et disques.
Les performances des différents SGBD sont intrinsèquement différentes, c'est un fait, mais c'est aussi la façon de les installer, configurer et utiliser qui pèse dans la balance. Les tests du benchmark sont ils faits après avoir optimisé avec soin chacun des SGBD considérés ?
Peu probable, il faudrait des DBA compétents pour chaque SGBD, ce qui coûte cher.

Citation:

---

Envoyé par escartefigue

Je ne sais quoi penser d'un tel benchmark (comme souvent du reste) dans la mesure où les SGBD sont différents mais aussi les machines qui les hébergent et les O/S qui les animent.
Il en va sans doute de même avec la qualité et quantité de RAM et disques.
Les performances des différents SGBD sont intrinsèquement différentes, c'est un fait, mais c'est aussi la façon de les installer, configurer et utiliser qui pèse dans la balance. Les tests du benchmark sont ils faits après avoir optimisé avec soin chacun des SGBD considérés ?

---

Non seulement les SGBDR sont optimisé, mais le matériel aussi. Le becnhmark porte sur la solution globale....

Citation:

---

Peu probable, il faudrait des DBA compétents pour chaque SGBD, ce qui coûte cher.

---

C'est ce qui fait que ce genre de benchmark coute cher !

A +

Citation:

---

Envoyé par StringBuilder

Malheureusement, cette pratique est particulièrement répandue pour plusieurs raisons :
...
Donc autant d'un point de vue SGBD pur, c'est plus ou moins stupide, autant pour les applications qui utilisent les SGBD ça ne se justifie pas forcément.
Avoir des utilisateurs types en fonction des profiles des utilisateurs finaux sera déjà plus logique, encore faut-il avoir des profiles fonctionnels justifiant un tel découpage (ce qui est incompatible avec une gestion fine des droits).

---

Oui, mais le RGPD est en train de changez la donne !
Comment fais tu pour tracer toutes les activités d'accès a tes données sensibles si tu a un seul compte qui y accède ?
ne pas oubliez que vous devez tracer en permanence les accès aux données sensibles et informer l'autorité de tutelle d'une intrusion illicite dans les 72 heures !

A +

L'un n'empêche pas l'autre.

Si je rencontre dans SQL Server une connexion avec un autre compte que celui de l'application, je sais que c'est potentiellement une intrusion.
Sinon, et si j'ai correctement restreint le compte en question, le PGI est parfaitement capable de loguer lui-même les accès.

Enfin, l'accès non autorisé aux données, ça me fait un peu rire, car la plupart du temps, audit activé ou non, personne ne le verra sur une application de PROD :
- personne ne va analyser les accès en lectures aux différents tables/lignes et vérifier que ça correspond à une demande légitime en permanence
- la plupart du temps, les fuites de données se font hors SGBD : détournement de sauvegarde, d'exports de données, etc. car c'est à la fois plus facile et moins tracé

Mais dans tous les cas, notifier les autorités d'une intrusion non autorisée, ça revient à mettre des caméras dans les rues :
- soit du abandonne ton métier, et du passe ton temps à surveiller les écrans
- soit tu enregistres tout, et ressort les vidéos quand l'autorité vient enquêter sur une intrusion : mais les logs ne font rien d'autre que des logs, et une intrusion peut parfaitement arriver dans des conditions parfaitement normales d'utilisation. accessoirement, que faut-il faire quand madame Michu charge par erreur la fiche de monsieur Dupont au lieu de Dupond ? Est-on dans le cas d'une "intrusion frauduleuse" ?

Bon, après, on dérape sur RGPD, on s'éloigne un peu du sujet ;)

Citation:

---

Envoyé par StringBuilder

L'un n'empêche pas l'autre.

Si je rencontre dans SQL Server une connexion avec un autre compte que celui de l'application, je sais que c'est potentiellement une intrusion.
Sinon, et si j'ai correctement restreint le compte en question, le PGI est parfaitement capable de loguer lui-même les accès.

---

la plupart des accès sont indirecte. Fait sur un poste client dont bien des choses sont restées "ouvertes"

Citation:

---

Enfin, l'accès non autorisé aux données, ça me fait un peu rire, car la plupart du temps, audit activé ou non, personne ne le verra sur une application de PROD :
- personne ne va analyser les accès en lectures aux différents tables/lignes et vérifier que ça correspond à une demande légitime en permanence

---

Si tu as des outils comme SQL Server database audit, c'est assez simple a automatiser et diagnostiquer des accès illicites.... L'outil étant intégré et hyper sécurisé : en particulier le database audit peut arrêter le serveur SQL en cas de dysfonctionnement.... Car en général les malfaiteurs commencent à couper la sécurité avant de commencer leurs méfaits....

A +