Ce genre de chose peut se comprendre pour des tables d'archives, pas ce n'est pas le cas ici.

Je serais du patron, j'aurais écrit :

INSERT INTO "pole_emploi" SELECT * FROM "salaries" WHERE NOM="<nom_du_gars>"
 DELETE FROM "salaries" WHERE NOM="<nom_du_gars>"

Maqis bon un patron qui touche en SQL, c'est comme Gargamel devenant pote avec les schtroumpfs.

Je crois que Gargamel devient pote avec les Schtroumpfs dans un volume de la BD...

me rappelle des monstruosités que j'avais trouvées dans du code que je devais reprendre… des index mysql sur des varchar, des INSERT INTO TABLE VALUES() sans nommer les champs, ce qui a obligé les gus à créer TROIS tables parlant de factures (ouvertes, payées, et un 3e statut)… au lieu de simplement pouvoir ajouter un champ…

Bref, je vois que le développement pourri a encore de beaux jours devant lui (ce dont je parle doit dater de 8 ans environ… sisi…)

Je compatis, Picc. Sincèrement.

J'ai mal aux yeux T_T

Allié serait plus exact. Quand quelque chose les menace tous ^^

A mon avis, un boolean, ça prenait plus de place qu'une copie entière de la table, m'voyez.

"des INSERT INTO TABLE VALUES() sans nommer les champs, ce qui a obligé les gus à créer TROIS tables"
Ah bon, pourquoi? Ok, c'est pas terrible de se baser sur la position des colonnes, mais ça s'étend facilement il me semble, par défaut en rajoutant ta colonne et tes nouvelles valeurs en derniers. Ou alors pour des factures tu peux très bien mettre une valeur par défaut pour le statut je pense (pas de maj des requetes), puis le faire évoluer par des updates?

Pour des performances de fou, il faut rajouter un index discret sur ton champ booléen après !

mais attention, SQL gère-t-il les trois états d'un booléen?
cf. http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

C'est marrant, mais juste en lisant le début de la phrase "En reprenant les développements d'un ancien collègue ..." je me suis préparé à toutes les horreurs possibles.
Enfin, je _croyais_ être préparé à toutes les horreurs possibles. Je vois que j'ai encore beaucoup à apprendre....

C'est vrai que quand on pense booléen, on pense "vrai / faux" (la logique même) ... sauf que dans certaines bases (toutes ?) c'est "vrai / faux / nul" qui sont acceptés.
Maintenant, pour l'exemple en question, un petit champ booléen avec FALSE comme valeur par défaut, ça aurait été plus propre, plus simple, plus économe en place et sans doute plus rapide à coder (et à interpréter)...
Décidément, il y en a qui aiment se compliquer la vie !^^

Ca pose problème (ou pas) s'il y a des homonymes dans la boite...

Les miens en ont saigné !

Là ce n'est pas seulement avec les bases de données relationnelles qu'il a un problème, c'est entre ses deux oreilles...

Merci beaucoup ! En plus, ce n'est qu'un échantillon !

Ce qui situe le problème entre une chaise, un clavier, une oreille droite et une oreille gauche ... il ne peut pas nous échapper, chef !

Surtout que comme le dit Tengu juste au-dessus, avec des requêtes comportant des colonnes non nommées si une table change l'autre doit changer dans la foulée sous peine d'explosage d'application à la face ^^

On ne connait pas la taille de l'entreprise.

Ceci est un approche utilisé dans les très grosses boites (mutuelles par exemple). Le but est de garder la table "factures" la plus petite possible pour accélérer accès aux données courants. Les facturés payés (et donc "archivés") ne seront plus jamais accédés dans la majorité des cas !

Attention, tout ceci est viable seulement si il y a un "delete from facture where id = ###" qui suis l'insert !

Au pire du pire, tu rajoutes un champ numérique avec 0/1/2, ça prend quand même monstrueusement moins de place

Non, là on a (enfin on avait, car j'ai eu vite fait d'y remettre de l'ordre) deux bonnes grosses tables bien redondantes, sans but d'archivage. Avec, qui plus est, une désynchronisation entre les enregistrements qui évoluaient dans une table et pas dans l'autre ...

C'est beau :)

"Ceci est un approche utilisé dans les très grosses boites (mutuelles par exemple). Le but est de garder la table "factures" la plus petite possible pour accélérer accès aux données courants. Les facturés payés (et donc "archivés") ne seront plus jamais accédés dans la majorité des cas !
Attention, tout ceci est viable seulement si il y a un "delete from facture where id = ###" qui suis l'insert !"

Je suis DBA et je n'ai jamais vu ça. tu devrais te renseigner sur ce qu'est un datawarehouse et des batchs d'archivage. En plus suivant le moteur de bdd utilisé, le delete risque de bloquer la table en écriture (ex MySQL)
Mais des insert et des deletes fréquents sur la même table dégradent les performances

Y en a pas un aussi où il perd la boule ?

Bon la c'est un PEBKAC mais le problème avec les PEBKAC SQL c'est que parfois le contexte est très important et donc on peut pas trop juger...

On attend le reste avec impatience !

Ce qui me semblait le plus important, c'était justement ce décalage que j'imagine non géré ! C'est là le plus gros des soucis, en imaginant que le gars n'ait pas d'expérience. Après, que ce soit écrit avec les pieds, si il n'y avait pas d'erreurs de gérées, on se retrouverait face à un OS commercial bien connu et très largement diffusé, donc très dispendieux en place.

Oui, à côté de ça,; j'imaginais que le gars ne traitait pas non plus l'effacement. Après, si on a un bon transfert... ça peut le faire.

Mettre en place deux tables à garder absolument identiques et cohérentes, gérer un insert + delete pour le transfert, tout cela pour un hypothétique gain de perf sur la table la plus utilisée ? faut vraiment qu'il y ai un énorme problème de perf et qu'il n'y ai pas d'autre solution utilisable, comme un partitionnement de la table par année

Je dirais que c'est une aussi bonne solution que d'utiliser des triggers ...

Ici, je ne crois pas qu'il s'agisse d'un problème de texte.

"Un volume de la BD"...

Je ne sais pas si le jeu de mots est volontaire mais pas mal!