Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3382 connectés 

 


Sujet auquel vous répondez
Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde
Jubijub

Kenshineuh a écrit :

Le plus drôle c'est quand même d'entendre parler de noogler grant, de vesting/vested, de L7/L8, de refreshers, cliff edge, de salaire à 500/600k, tout en ne pouvant rien faire pendant une semaine sans que ça se voit.
 
Entre ça et les posts de Nray, ce topic est lunaire pour moi. :o
 


C’est vrai pour tous les jobs à L7 et au delà : tes actions se voient (ou se voient pas) a des horizons bien plus long. Après quand je dis “rien faire” c’est en gros quand même aller aux meetings, faire mes devoirs de manager, etc… mais c’est en gros pas forcer le soir et surtout rien foutre du vendredi :D
 
Mais oui c’est assez dingue j’aurais jamais pensé ne serait-ce que 5 ans en arrière avoir ce type de revenus


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
Jubijub Bisous aux grenoblois depuis l’A49, direction Fontvieille. En espérant que ça bouchonne pas trop.
skeye

masklinn a écrit :


Mais d'autres fois c'est notablement moins rapide parce-que ça taxe ton serveur de DB alors que t'as des app serveurs à pas savoir quoi foutre, donc même là ça reste du gros cas par cas.


J'ai pas dit que c'était une bonne solution dans tous les cas...mais parfois ça se tient :D

masklinn

skeye a écrit :

C'est parfois significativement plus rapide sur certains traitements lourds, comparé à la même chose avec la techno "cliente".


Mais d'autres fois c'est notablement moins rapide parce-que ça taxe ton serveur de DB alors que t'as des app serveurs à pas savoir quoi foutre, donc même là ça reste du gros cas par cas.

skeye

Flaie a écrit :

les procédures stockées c'est un putain d'enfer.
Y'a très peu de raisons pour que ce soit un bon choix.
Mis à part le partage comme évoqué par le mask ou bien une grosse intelligence pour faire du reporting sinon je ne vois pas.
et c'est la merde à tester, déployer etc

 

C'est parfois significativement plus rapide sur certains traitements lourds, comparé à la même chose avec la techno "cliente". Et anciennement c'était un moyen de factoriser les traitements métier pour plusieurs clients de la base - ce que tu fais de nos jours avec une API.

Flaie les procédures stockées c'est un putain d'enfer.
Y'a très peu de raisons pour que ce soit un bon choix.
Mis à part le partage comme évoqué par le mask ou bien une grosse intelligence pour faire du reporting sinon je ne vois pas.
et c'est la merde à tester, déployer etc
masklinn

el muchacho a écrit :

Tu prends l'exemple le plus simple, là, et en Python en plus. Dès que tu as des requêtes un peu complexes, on est content de ne pas avoir ce mix de C++ et de SQL.


Non [:spamafote] Pour les requêtes complexes t'as le même overhead, et en plus t'as du SQL dans du PL et c'est encore plus merdique, parce que ton meta est un tas de boue.

 

Le seul scénario où je suis content des procs (encore une fois en dehors du scénario où des projets indépendants vont taper dans la db) c'est si quelqu'un d'autre se tape le SQL, au quel cas effectivement RAB de s'ils vont ça d'un côté ou de l'autre c'est plus mon problème.

el muchacho [

DDT a écrit :


Y a très longtemps j'ai utilisé myBatis en Java (je sais pas ce que mon équipe avait contre Hibernate/JPA) et ça me semblait pas trop mal comme concept si tu veux pas un ORM.


Oui MyBatis a le bon niveau d'abstraction, je trouve.

el muchacho

masklinn a écrit :


Bah si c'est juste qu'elle est construite dans la PS, et qu'en plus tu dois faire une traduction supplémentaire.
Version PS:

Code :
  1. cr.callproc('get_thing', [id])
  2. result = cr.fetchall()


Code :
  1. CREATE FUNCTION get_thing(id integer)
  2.  returns setof sometable
  3. AS
  4. $$
  5. SELECT *
  6. FROM sometable
  7. WHERE id = id;
  8. $$
  9. LANGUAGE sql;


Version pas PS:

Code :
  1. result = get_thing(id)


Code :
  1. def get_thing(id):
  2.    cr.execute("select * from sometable where id = ?", [id])
  3.    return cr.fetchall()


La version PS est juste plus chiante à maintenir avec encore plus de points d'erreur possibles, pour un gain intrinsèque plus ou moins absent (si tu utilises une DB qui typecheck les stored proc de manière extensive ça peut voir des erreurs de codage à l'installation mais je crois pas que ce soit le cas de postgres)
 [:michel_cymerde:7]  


Tu prends l'exemple le plus simple, là, et en Python en plus. Dès que tu as des requêtes un peu complexes, on est content de ne pas avoir ce mix de C++ et de SQL.

el muchacho

Hermes le Messager a écrit :

 

Je suis devenu officiellement développeur (c'est à dire avec un vrai job title dans un boite) à 43 ans. Les deux ans qui ont précédé, j'étais dev mais mon job title c'était support engineer. :D Rien n'est jamais perdu... On peut même devenir CTO.

 

Mais bon, on va pas se mentir non plus, l'info était ma seconde passion après la musique et j'en ai toujours plus ou moins fait et avec des bases de prog dès l'age de 14 ans.

 

Ça semble quand même difficile à 47 ans de s'y mettre... Maintenant, je dirais que tout est affaire de motivation. Si le mec a une vie de famille, des amis, une maison à entretenir etc... Je dirais que c'est mort. Ce genre d'exploit n'est possible qu'en bossant de manière passionnée toute la journée, WE compris. :o

 

Quant au fait d'être recruté par une boite sans exp à on va dire 50 ans (vu que si le mec s'y met à fond comme un malade, 3 ans ne seront pas de trop), c'est pas gagné. Ceci dit, on manque tellement cruellement de devs ici par exemple que c'est possible.

 

Le meilleur espoir à cet age là sans exp, c'est de se mettre en freelance, mais sans exp, le freelance, c'est un très gros piège car tu essuies les plâtres avec tes premiers clients (voire même tous tes clients pendant un bon moment  [:bool_de_gom] )

 



hephaestos a écrit :

34 ans ici, mais j'ai pris la décision à 25. Ça me semble chaud de commencer de rien à 47 ans...

 
Plam a écrit :

 

ça me parait tout à fait faisable au contraire. Tout le monde va pas bosser chez Gougueul hein :)

 

Quelqu'un de motivé et qui a de bon soft skills y arrivera de toute façon :)


Non mais je m'en fous, allez lui répondre à lui, pas à moi.

hephaestos La chiasserie pas webscale c'est spanner ? Je comprend rien, là...
tryptique

DDT a écrit :


Du coup vous devez supporter une chiasserie pas vraiment webscale en interne avant de la proposer aux clients externes, qui eux ont au moins l'excuse de devoir migrer des vieilleries vers GCP.
Marrant. :D

 



Il fait du SQL, son problème n'est clairement pas webscale :o :o

DDT

hephaestos a écrit :


 
On les a dans le vrai spanner en interne, ça devrait arriver :o
 


Du coup vous devez supporter une chiasserie pas vraiment webscale en interne avant de la proposer aux clients externes, qui eux ont au moins l'excuse de devoir migrer des vieilleries vers GCP.
Marrant. :D
 

hephaestos a écrit :


J'ai pas compris, tu peux élaborer...


https://getquill.io par exemple.
 
Je connais pas Entity Framework mais j'imagine que ça use et abuse de réflexion.
Si tu veux pas ça, il te faut de la génération de code, ou mieux, des macros.

hephaestos

 

On les a dans le vrai spanner en interne, ça devrait arriver :o

 


DDT a écrit :


- Dans l'autre sens, construire des requêtes avec une API fonctionnelle et dériver des codecs à partir d'objets. C'est l'approche plus lisible et naturelle mais évidemment plus contraignante.
.


J'ai pas compris, tu peux élaborer...

DDT

hephaestos a écrit :


Calomnie, on a des générateurs de séquences ! ( Ou alors je comprends pas à quoi tu fais référence)
 
Et oui il n'y a pas de procédures stockées, qui pour être honnête ne me manquent pas franchement. Même si effectivement ça permettrait de découpler un peu et de forcer à avoir des requêtes bien foutues avec une interface commode, et relue séparément. Mais je ne demande pas seulement pour trouver des alternatives, plutôt pour savoir ce que vous tolérée de votre côté, si je suis déraisonnable de demander de ne pas utiliser ça autant que possible.


Je suis resté à ce que la doc raconte:
https://cloud.google.com/spanner/do [...] #sequences
https://cloud.google.com/solutions/ [...] ud-spanner
 
Perso je fais pas trop de relationnel, mais j'ai un langage qui a des macros puissantes donc on peut soit:
- Typer du SQL quasiment brut (des chaînes interpolées). C'est ce qu'on fait. Ça me semble raisonnable, si je débarque sur du code que j'ai pas écrit, je prends la requête comme une boîte noire, la signature devrait me suffire. À moins qu'il y ait un problème avec celle-ci et de toute manière je vais devoir la reprendre en dehors de mon IDE.
- Dans l'autre sens, construire des requêtes avec une API fonctionnelle et dériver des codecs à partir d'objets. C'est l'approche plus lisible et naturelle mais évidemment plus contraignante.
 
Y a très longtemps j'ai utilisé myBatis en Java (je sais pas ce que mon équipe avait contre Hibernate/JPA) et ça me semblait pas trop mal comme concept si tu veux pas un ORM.

theShockWave

Hermes le Messager a écrit :

 

Avec enfant et vie de famille "normale" participative, ça doit être très très dur. Surtout si madame travaille et que monsieur est dans une config où c'est lui qui s'occupe des enfants. Quand je vois le temps qui me reste (c'est à dire 0,00 seconde) tous les jours... Et je n'ai même plus de loisirs...

 

Bon là madame et les enfants sont sur le continent et je suis seul encore 2 semaines... (avec plein de missions à faire pour la maison etc...) Ben du coup, j'ai pu me remettre à jouer un peu aux jeux vidéos. Je me suis pris le dernier tomb raider et surtout Disco Elysium. :o

 

Joue au jeu du Bayou ! (et pour ceux qui disent qu'il est mort, le graph va plutôt vers le haut : https://steamcharts.com/app/594650 )

Hermes le Messager

Jubijub a écrit :


 
J’ai pas trop accroché, c’est très space comme jeu


 
Je suis mort d'une crise cardiaque, faut que je recommence. :o  
 
Effectivement, c'est un jeu vraiment atypique, un mélange de RPG et de point and click genre les chevaliers de Baphomet. Mais j'ai pas mal accroché. ça me rappelle aussi vaguement Machinarium bien que l'esthétique soit différente et que c'était une autre époque. Il y a énormément de paroles, c'est tentant de zapper, mais si on le fait, on passe à côté du jeu.  
 
Concernant le dernier tomb raider, on est trop guidé comme sur un rail. Les interactions avec les autres personnages sont trop limitées... Pour le moment plutôt déçu. Les énigmes sont téléphonées... Bref, pas terrible, mais c'est distrayant.

___alt


 
Yikes  [:altherac:1]

masklinn

Kenshineuh a écrit :

Balade toi sur son compte et enjoy. :o


Non je vais pas faire ça, j'ai vu deux messages et... ew

Jubijub

Hermes le Messager a écrit :


Ben du coup, j'ai pu me remettre à jouer un peu aux jeux vidéos. Je me suis pris le dernier tomb raider et surtout Disco Elysium. :o


 
J’ai pas trop accroché, c’est très space comme jeu

Kenshineuh Balade toi sur son compte et enjoy. :o
masklinn


 [:shlavos]

Spoiler :

Il est français ce truc?

Kenshineuh Vive la France.  
 
https://twitter.com/m_ou_se/status/1553322611903447042
 
https://twitter.com/windowscpp/stat [...] 3368312832
 
Hermes le Messager

Plam a écrit :


 
ça me parait tout à fait faisable au contraire. Tout le monde va pas bosser chez Gougueul hein :)
 
Quelqu'un de motivé et qui a de bon soft skills y arrivera de toute façon :)


 
Avec enfant et vie de famille "normale" participative, ça doit être très très dur. Surtout si madame travaille et que monsieur est dans une config où c'est lui qui s'occupe des enfants. Quand je vois le temps qui me reste (c'est à dire 0,00 seconde) tous les jours... Et je n'ai même plus de loisirs...  
 
Bon là madame et les enfants sont sur le continent et je suis seul encore 2 semaines... (avec plein de missions à faire pour la maison etc...) Ben du coup, j'ai pu me remettre à jouer un peu aux jeux vidéos. Je me suis pris le dernier tomb raider et surtout Disco Elysium. :o

hephaestos

Plam a écrit :

 

ça me parait tout à fait faisable au contraire. Tout le monde va pas bosser chez Gougueul hein :)

 

Quelqu'un de motivé et qui a de bon soft skills y arrivera de toute façon :)


Ouais, c'est pas faux. Puis de toutes façons c'est un peu con ce que j'ai dit, parce que j'ai pris la décision à 25 ans mais j'ai tout de suite aimé programmé dans mon travail et à côté, même si j'avais pas le titre de développeur. Je retire.

Plam

hephaestos a écrit :

34 ans ici, mais j'ai pris la décision à 25. Ça me semble chaud de commencer de rien à 47 ans...


 
ça me parait tout à fait faisable au contraire. Tout le monde va pas bosser chez Gougueul hein :)
 
Quelqu'un de motivé et qui a de bon soft skills y arrivera de toute façon :)

hephaestos 34 ans ici, mais j'ai pris la décision à 25. Ça me semble chaud de commencer de rien à 47 ans...
Hermes le Messager


 
Je suis devenu officiellement développeur (c'est à dire avec un vrai job title dans un boite) à 43 ans. Les deux ans qui ont précédé, j'étais dev mais mon job title c'était support engineer. :D Rien n'est jamais perdu... On peut même devenir CTO.
 
Mais bon, on va pas se mentir non plus, l'info était ma seconde passion après la musique et j'en ai toujours plus ou moins fait et avec des bases de prog dès l'age de 14 ans.
 
Ça semble quand même difficile à 47 ans de s'y mettre... Maintenant, je dirais que tout est affaire de motivation. Si le mec a une vie de famille, des amis, une maison à entretenir etc... Je dirais que c'est mort. Ce genre d'exploit n'est possible qu'en bossant de manière passionnée toute la journée, WE compris. :o
 
Quant au fait d'être recruté par une boite sans exp à on va dire 50 ans (vu que si le mec s'y met à fond comme un malade, 3 ans ne seront pas de trop), c'est pas gagné. Ceci dit, on manque tellement cruellement de devs ici par exemple que c'est possible.  
 
Le meilleur espoir à cet age là sans exp, c'est de se mettre en freelance, mais sans exp, le freelance, c'est un très gros piège car tu essuies les plâtres avec tes premiers clients (voire même tous tes clients pendant un bon moment  [:bool_de_gom] )
 

hephaestos

nucl3arfl0 a écrit :

 

Si tu as des soucis de confiance en soi, c'est pas conseillé de venir ici parce que sinon tu prends cher [:fredouye]


Ça a radicalement changé pour depuis que je bosse à Google. Tu dis toi même que tu ne corps professionnellement que des mauvais ; c'était plus ou moins mon cas. J'ai croisé quelques bons avant mais c'étaient des exceptions.

 

Dans une boîte comme Google, le niveau global est bon, et ça donne une pleine opportunité de connaître son propre niveau par rapport aux autres. Je côtoie de nombreux cadors, et je suis vision de bureau de pointures mondiales. À côté de ça, il y a beaucoup de bons, et pas mal de médiocres. Peu de mauvais mais on en a. Bref, avoir un gros échantillon pertinent à portée ça m'a aidé à été serein par rapport à mon niveau technique. Je ne me fais pas d'illusion, mais le syndrome de l'imposteur est aussi assez loin derrière. En corollaire, il y a pas mal de moments où je femme ma gueule parce que j'ai simplement pas le niveau ; mais quand je l'ouvre, c'est dans complexes.

hephaestos

masklinn a écrit :


Tu peux faire ça en imposant que le SQL soit dans des modules d'interaction DB, dédiés.


Non mais évidemment mais ça reste du C++, quoi. C'est déjà pénible de lire du SQL ou du C++ indépendamment, quand faut comprendre le SQL généré par le C++, perso je renonce...

 

Mais bon, compris, le C++ c'est un langage de bonhommes en gros, fait que j'arrête de chouiner...

 

(Je crois qu'on a un ORM qu'en java et j'en ai entendu plutôt du mal...)

hephaestos

DDT a écrit :


Spanner supporte pas les procédures stockées. :D
Même pas les générateurs de séquences.


Calomnie, on a des générateurs de séquences ! ( Ou alors je comprends pas à quoi tu fais référence)

 

Et oui il n'y a pas de procédures stockées, qui pour être honnête ne me manquent pas franchement. Même si effectivement ça permettrait de découpler un peu et de forcer à avoir des requêtes bien foutues avec une interface commode, et relue séparément. Mais je ne demande pas seulement pour trouver des alternatives, plutôt pour savoir ce que vous tolérée de votre côté, si je suis déraisonnable de demander de ne pas utiliser ça autant que possible.

masklinn

el muchacho a écrit :

Ca rend le code client plus propre car il n'a pas à construire les requêtes


Bah si c'est juste qu'elle est construite dans la PS, et qu'en plus tu dois faire une traduction supplémentaire.
Version PS:

Code :
  1. cr.callproc('get_thing', [id])
  2. result = cr.fetchall()


Code :
  1. CREATE FUNCTION get_thing(id integer)
  2.  returns setof sometable
  3. AS
  4. $$
  5. SELECT *
  6. FROM sometable
  7. WHERE id = id;
  8. $$
  9. LANGUAGE sql;


Version pas PS:

Code :
  1. result = get_thing(id)


Code :
  1. def get_thing(id):
  2.    cr.execute("select * from sometable where id = ?", [id])
  3.    return cr.fetchall()


La version PS est juste plus chiante à maintenir avec encore plus de points d'erreur possibles, pour un gain intrinsèque plus ou moins absent (si tu utilises une DB qui typecheck les stored proc de manière extensive ça peut voir des erreurs de codage à l'installation mais je crois pas que ce soit le cas de postgres)
 [:michel_cymerde:7]

el muchacho a écrit :

Du coté base, c'est du SQL tout ce qu'il y a de plus standard.


Si c'est du SQL "tout ce qu'il y a de plus standard" (pas de construction dynamique, pas de processing procédural) c'est trivial à faire côté client.

 

Si c'est du SQL pas trivial, c'est tout aussi dégueulasse dans la stored proc (voire pire, parce que t'as pas de query builder dont c'est le job).

el muchacho a écrit :

Il n'y a pas de leak de SQL dans le code C++ via une meilleure séparation des couches.


Tu peux faire ça en imposant que le SQL soit dans des modules d'interaction DB, dédiés.

Kenshineuh

tryptique a écrit :


On n'utilise pas de bases de données relationnelles. Nos requêtes se limitent à getByKey sur une base NoSQL.


 
Ah, toi aussi tu bosses à PlamCorps. :o

tryptique

hephaestos a écrit :

Il existe quoi dans la nature comme moyen d'accéder à des bases de données depuis le code applicatif ?

 

J'ai fait un peu d'entity framework avant, c'était mon premier contact avec une base de données : on écrit du code naturel, les données sont considérées comme des collections natives et le code est converti en requêtes au runtime, je trouve ça chouette.

 

Ici on n'a rien de tel, du coup on doit avoir des accès explicites. Je trouve ça tellement horrible j'ai du mal à croire que ce soit l'état de l'art... Le pire je trouve c'est quand on se retrouve à injecter du SQL (synthétisé avec des constexpr en C++) ; c'est déjà compliqué de lire du SQL. Si en plus il fait comprendre le code qui le synthétise et savoir deviner comment ça se comportera au runtime je trouve ça difficilement acceptable. Mais bon, j'ai l'impression que je suis le seul que ça dérange. Je suis une chochotte, ou j'ai raison ? Vous gérez comment ?


On n'utilise pas de bases de données relationnelles. Nos requêtes se limitent à getByKey sur une base NoSQL.

 

Ça n'aide pas je sais :o

el muchacho

masklinn a écrit :


C'est une approche qui ne vaut vraiment le couop que si tu as plusieurs clients qui tapent dans la base et que tu veux contrôler les accès, ou plus généralement que tu fais pas confiance aux clients mais que tu veux / peux pas avoir de broker (tes stored procs te servent d'API), mais pour une relation 1:1 c'est ultra chiant, la moindre interrogation de db impose d'aller mettre à jour le schéma pour ajouter ou éditer une procédure stockée habituellement codée dans un langage bancal que t'as pas envie de toucher. Et au final t'y gagnes rien: ta proc stockée pourrait être une fonction / méthode, t'aurais moins d'overhead à l'appel, moins de chances de te planquer, et plus de vérifications.

 

Ca rend le code client plus propre car il n'a pas à construire les requêtes, il se contente d'appeler les méthodes exposées par l'API. Du coté base, c'est du SQL tout ce qu'il y a de plus standard.
Il n'y a pas de leak de SQL dans le code C++ via une meilleure séparation des couches. Mais oui, c'est plus chiant coté déploiement, ça ne fait aucun doute.

DDT

el muchacho a écrit :

 

Vous pouvez faire des procédures stockées, les requêtes sont stockées en base au lieu d'être générées coté client.


Spanner supporte pas les procédures stockées. :D
Même pas les générateurs de séquences.

el muchacho Commencer dans le web à 47 ans ?
https://forum.hardware.fr/hfr/Progr [...] 8268_1.htm
hephaestos

boblenain200 a écrit :

 

Il est typesafe le SQL généré à la compilation (il vérifie par rapport à un modele donné et/ou une vrai DB comme https://github.com/launchbadge/sqlx par exemple) ?


Édit, j'avais pas bien lu le message. Non.

masklinn

hephaestos a écrit :

Il existe quoi dans la nature comme moyen d'accéder à des bases de données depuis le code applicatif ?

 

J'ai fait un peu d'entity framework avant, c'était mon premier contact avec une base de données : on écrit du code naturel, les données sont considérées comme des collections natives et le code est converti en requêtes au runtime, je trouve ça chouette.

 

Ici on n'a rien de tel, du coup on doit avoir des accès explicites. Je trouve ça tellement horrible j'ai du mal à croire que ce soit l'état de l'art... Le pire je trouve c'est quand on se retrouve à injecter du SQL (synthétisé avec des constexpr en C++) ; c'est déjà compliqué de lire du SQL. Si en plus il fait comprendre le code qui le synthétise et savoir deviner comment ça se comportera au runtime je trouve ça difficilement acceptable. Mais bon, j'ai l'impression que je suis le seul que ça dérange. Je suis une chochotte, ou j'ai raison ? Vous gérez comment ?


En faisant pas de C++ [:jar jar]

 

Je présume que EF est un ORM, donc ça a l'avantage d'être très haut niveau et naturel (s'il est bon en tout cas) mais ça demande beaucoup d'infra en dessous, et ça tend à être inflexible et inefficace (genre il est difficile d'optimiser tes requêtes au maximum ou de tirer un maximum des spécificités de la DB).

 

Je suis pas sûr qu'un ORM se trouve pour du C++, et pour les raisons au dessus plus les langages sont bas niveau plus les ORMs ont tendance à donner des boutons (et généralement les ORMs marchent par réflection, ou alors il faut des montagnes de codegen, c'est d'autant plus difficile en C++).

 

Faut probablement plus regarder du côté des DAO (pour l'organisation) et des query builders (pense linq for sql).

Jubijub a écrit :

Il a du être estimé que les ORM bouffent trop de perf


Ou bien le projet a démarré petit et personne a remis le problème en question.

 
el muchacho a écrit :

Vous pouvez faire des procédures stockées, les requêtes sont stockées en base au lieu d'être générées coté client. La base présente alors une API de requêtes possibles que le client appelle. Cette manière de faire est assez élégante, je touve, mais le déploiement est plus compliqué puisqu'il faut le faire dans la base de données et bien sûr s'assurer de la compatibilité entre le code client et la base.


C'est une approche qui ne vaut vraiment le couop que si tu as plusieurs clients qui tapent dans la base et que tu veux contrôler les accès, ou plus généralement que tu fais pas confiance aux clients mais que tu veux / peux pas avoir de broker (tes stored procs te servent d'API), mais pour une relation 1:1 c'est ultra chiant, la moindre interrogation de db impose d'aller mettre à jour le schéma pour ajouter ou éditer une procédure stockée habituellement codée dans un langage bancal que t'as pas envie de toucher. Et au final t'y gagnes rien: ta proc stockée pourrait être une fonction / méthode, t'aurais moins d'overhead à l'appel, moins de chances de te planquer, et plus de vérifications.

el muchacho

hephaestos a écrit :

Il existe quoi dans la nature comme moyen d'accéder à des bases de données depuis le code applicatif ?
 
J'ai fait un peu d'entity framework avant, c'était mon premier contact avec une base de données : on écrit du code naturel, les données sont considérées comme des collections natives et le code est converti en requêtes au runtime, je trouve ça chouette.
 
Ici on n'a rien de tel, du coup on doit avoir des accès explicites. Je trouve ça tellement horrible j'ai du mal à croire que ce soit l'état de l'art... Le pire je trouve c'est quand on se retrouve à injecter du SQL (synthétisé avec des constexpr en C++) ; c'est déjà compliqué de lire du SQL. Si en plus il fait comprendre le code qui le synthétise et savoir deviner comment ça se comportera au runtime je trouve ça difficilement acceptable. Mais bon, j'ai l'impression que je suis le seul que ça dérange. Je suis une chochotte, ou j'ai raison ? Vous gérez comment ?


 
Vous pouvez faire des procédures stockées, les requêtes sont stockées en base au lieu d'être générées coté client. La base présente alors une API de requêtes possibles que le client appelle. Cette manière de faire est assez élégante, je touve, mais le déploiement est plus compliqué puisqu'il faut le faire dans la base de données et bien sûr s'assurer de la compatibilité entre le code client et la base.

Jubijub

Kenshineuh a écrit :

Le plus drôle c'est quand même d'entendre parler de noogler grant, de vesting/vested, de L7/L8, de refreshers, cliff edge, de salaire à 500/600k, tout en ne pouvant rien faire pendant une semaine sans que ça se voit.
 
Entre ça et les posts de Nray, ce topic est lunaire pour moi. :o
 


C’est vrai pour tous les jobs à L7 et au delà : tes actions se voient (ou se voient pas) a des horizons bien plus long. Après quand je dis “rien faire” c’est en gros quand même aller aux meetings, faire mes devoirs de manager, etc… mais c’est en gros pas forcer le soir et surtout rien foutre du vendredi :D
 
Mais oui c’est assez dingue j’aurais jamais pensé ne serait-ce que 5 ans en arrière avoir ce type de revenus

boblenain200

hephaestos a écrit :


Ici on n'a rien de tel, du coup on doit avoir des accès explicites. Je trouve ça tellement horrible j'ai du mal à croire que ce soit l'état de l'art... Le pire je trouve c'est quand on se retrouve à injecter du SQL (synthétisé avec des constexpr en C++) ; c'est déjà compliqué de lire du SQL. Si en plus il fait comprendre le code qui le synthétise et savoir deviner comment ça se comportera au runtime je trouve ça difficilement acceptable. Mais bon, j'ai l'impression que je suis le seul que ça dérange. Je suis une chochotte, ou j'ai raison ? Vous gérez comment ?


 
Il est typesafe le SQL généré à la compilation (il vérifie par rapport à un modele donné et/ou une vrai DB comme https://github.com/launchbadge/sqlx par exemple) ?


Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)