Reprise du message précédent :
C'est clair que Dev et DBA, ça n'a rien à voir, je peux te le confirmer étant ni l'un ni l'autre et devant toucher aux deux
 
Mais Postgre est un bon choix, en plus ça permet de faire de la recherche full text (qui est complètement à l'opposée de la philosophie d'une DB mais bref passons )
 
Et le manuel est pas trop mal fait

après si tu as une Infra avec de GROS esxi, avec des pool de ressources bien définis ect ect la oui le SGDB ça peut être tenable.
 
Mais bon, j'ai vue pas mal de fois des VM sans limites d'I/O, pas de pool de ressources ect. Tu fais une install de VM et ta les perfs des autres qui se cassent la gueule  .
 
j'aurais tendance à ne pas virtualiser un SGBD sachant que c'est très sensible aux perturbations  
 
Si y'a besoin du max de perf, pourquoi rajouter une couche d'abstraction pour allouer toutes les ressources à la VM  

tu vires cette merde tu achetes un synology et ca marche en 3 clics

Des couches d'abstraction y en a maintenant à tous les niveaux (cf: ce que j'explique côté dev).
Et tant qu'à faire, tu lui colles un SAN dédié à ton SGBD ?

 
Dans la pratique je dirais oui, dans les faits j'ai quand même passer du temps à piger pourquoi ça ne pouvait pas fonctionner, j'ai appris des trucs et de ce côté là je vois l'utilité de mon alternance

 
Bas ça dépend si il faut le max de perf .

 
Mais t'avais pas commandé un ESx pour monter un cluster VmWare ?

Oui et ceci n'est pas négociable.  
 

Ah c'est clair qu'avec tous ces nouveaux frameworks qui pondent automatiquement de belles requêtes SQL, j'en vois passer des vertes et des pas mures.
Mais je vois aussi des code postaux dans du varchar(4000), des suppression de données qui ne suppriment pas en cascade les données dépendantes car il n'y a pas de contraintes et le dev n'en a pas tenu compte non plus dans son code, des doublons de données car il y a pas les contraintes d'unicité, des données redondées sans aucune raison...
 

c'est exactement ça, et c'est pourtant ce qu'ils font    

C'est une réflexion à faire en amont, avec les coûts associés qui vont bien.
Là où je te rejoints, c'est que c'est relativement bien négligé par beaucoup de personnes.

Le framework pond les requêtes qu'on lui demande.
Selon ton mode de développement (DbFirst, CodeFirst), c'est pas toujours le framework qui impose le "type" de données.
Et même en CodeFirst, il existe désormais la possibilité de bien typer les données.
Ceux qui bourrent des données dans des champs non adaptés, c'est juste qu'ils ont rien pigé ou ne veulent pas chercher à comprendre.
Idem pour les contraintes d'unicité, la redondance, etc.
Avec la généralisation des ORMs, il y a une forte augmentation des négligences sur le stockage des données.
Là où je trouve que les torts sont partagés, c'est que le DBA devrait intervenir dès le début du projet (si développement logiciel) pour inculquer les conventions et les bonnes pratiques.
Les idées préconçues sont encore bien dans les moeurs (ex: oulalala, y a beaucoup de jointure, c'est illisible, je stocke toute dans une même table Avoir beaucoup de jointure n'est pas une tare, et si ça devient illisible, il y a les vues qui sont faites pour ça)

 
C'est surtout que de nos jours avoir encore des OS installé directement sur du physique c'est complètement aberrant en terme de gestion.  
 
Si tu dimensionne et configure correctement ton infra les SQL en VM ça passe très bien.
On fait tourner des usines avec des besoins de perfs énorme sur du SQL Server/Windows en VM
On peut faire tourner du Hana sur des VM aussi maintenant et ça marche très bien aussi.
 
 

En ayant dimensionné le besoin en amont clairement.
 
Mais c'est du bon sens et ça s'applique à d'autres domaines que l'informatique.

Ok

Ça tombe bien, t'as SQL server sous Linux maintenant

Oui voilà, et avec ces nouveaux outils il faut pisser le code encore plus vite car le logiciel doit être en production pour avant-hier.
 

Malheureusement je bosse en exploitation et je n'ai pas mon mot à dire sur la conception des schémas des bases. Je suis coincé entre les logiciels mal pensés qu'on me livre et les serveurs sous-dimensionnés qu'on me fournit, d'où mon aigritude qui me conduit sur ce topic.
 

blasphème ! au feu les hérétiques !

 
On à les 3/4 de nos serveurs qui tournent sur du physique. On s'en sort très bien, on faisait comment avant sans la virtu  .  
La virtu ça coute cher pour avoir des performances, et le surcout est surtout énorme    

 
non mais un truc géré aux petits onions avec de bon admins VMware oui.
Mais dans le "il faut économiser, on à des petits ESX, fouttez moi ça la dessus" et après ça gueule parce que les performances sont dégueulasses

Ah donc tu voulais dire "n'importe quel soft sur une plateforme mal dimensionnée ça fonctionne pas top"

Tu peux mettre à jour ton serveur d'impression 2008r2 en 2012r2 puis en 2016 (moins sûr pour la dernière partie)
Nos dc2012r2 sont des 2008r2 upgradés

Et postgres sous Windows, mais c'est lent

 
Sans reboot, à chaud ?

Heu non

 
Ce qui est bien si ta pas le choix (en tant qu'admin, on te réclame du MS-SQL, mais tu veux pas te faire chier avec des licenses/admin Windows).
 
Par contre si ta le choix et que t'es sous Linux déjà, utiliser MS-SQL alors que ta PostGres, je comprend pas le projet  

 
Avant c'était chian
 
Là sans bouger mon cul du bureau je peux ajouter de la RAM, du CPU, copier une VM.
Si j'la foire je la restaure en 2 clic et en moins de 20min.
 
je te défie de faire pareil avec tes physiques
 
Pour le surcout je te rejoins, il faut sans doute avoir une certaine taille critique pour que ce soit vraiment rentable.

Du toute façon, avec la conteneurisation des services, la virtualisation sera encore plus "forte" que maintenant côté base de données.

 
ça dépend du cahier des charges. Si c'est pour avoir le MAX de perf, faire de la virtu est une abération.
 
On à des serveurs à 60K€ qui nous servent à peu près de gitlab avec pas mal de monde qui bosse dessus.  
Bien même avec 40 coeurs physique dans la machine, 70GB de ram  le load monte à  plus de 80%. Pour le fun, on à calculé pour virtualiser ces serveurs. Bien ça montait à plus de 90K€ pour avoir des perfs en moins  

 
Et Dieu inventa les cartes Ilo et le boot PXE  

Uh.
 
La vache.
 
T'as combien de machines sur ton parc pour avoir une bête pareil ?

T'as combien d'users sur ton gitlab ?

 
Pas forcément lié aux nombre de machines. Quand on avait un service R&D local, ils avaient un cluster à 110K, pour trois personnes.
 
Et là pareil, tu n'envisages même pas la virtu une seconde.

 
C'est pas un gitlab, c'est un truc homemade assez gros    
 

 
Assez pour foutre à genoux ces serveurs  

Ouais spontanément j'ai pensé à un bête serveur windows avec AD tout le tralala.
 
110k pour 3 personnes. Hmmm. La machine que tu veux pas planter.

 
Oui bon là forcément
C'est pas vraiment un cas classique ça, encore que ça dépend ce que fait ta boite du coup.

 
Ah non nous c'est de la R&D sous Nunux  .

Le boss parlait de passer sous Linux le serveur principal et ensuite il a parlé de passer à Sage pour sa gestion commerciale.
 
Je vais creuser la question de savoir si c'est jouable ou pas.
 
J'ai une syncho de NAS à voir aussi, y'a des petits trucs sympas qui commencent à arriver.
 
Qu'il est loin le (mauvais) temps où je faisais du php/ajax/html 8h par jour

Chez nous c'est des serveurs à 5-10k€ avec des vmware standard

Ah bon, faut que je prévienne mes clients alors...

 
ça dépend du cahier des charges  

 
Standard ? Genre la licence où il manque un paquet de trucs ?

Tu fais un prix intéressant sinon sur la version full inclusive ? Avec un bonus en drogue/prostitué.e.s (écriture inclusive offerte ) ?