Reprise du message précédent :

c'est une blague sexuelle?

les valeurs d'objectClass, oui. la definition de classes, spa gagné.
faux edit: a priori c'est les meme, /etc/ldap/schema est identique.

faut edit^2: trouved. y'avait une limite a 500 records retourné pour un resultat de recherche. Nombre qui a effectivement été dépassé tout récemment je crois. Avec les requetes qui donnaient des resultats coherents, j'étais juste en dessous.

Par contre le truc chelou, c'est que sur le slave, cette limite est appliquée au client en command line, mais pas au client remote/java, par contre. Sur le master, ça semble etre appliqué sur les deux, d'ou mon erreur.

Now si y'avait moyen de détecter le "warning" coté java ça serait bien, tiens. J'ai setté la limite a 1000 donc ça va resauter dans 6 mois.

http://www.lemonde.fr/sante/articl [...] 51302.html
 
en fait le probleme c'est le vocabulaire ?

surtout que

on se demande vraiment sur quoi ils réagissent...

Gatsu se barre et c'est la fin du monde http://frenchweb.fr/le-groupe-full [...] tion/92267

Prem's

Merci
 
Faudra que je teste avec une version récente de SQL Server

DELETE FROM matable
WHERE (champ1, champ2, champ3) IN
(
    SELECT champ1, champ2, champ3
    FROM matable
    WHERE blablabla
 
    MINUS
 
    SELECT champ1, champ2, champ3
    FROM monautretable
    WHERE blablabla
)

C'est pas exactement équivalent a une jointure sur ces 3champs ? Une inner joins pour le in  
Une left join where distant.id Is null pour le minus

Ce logo

Maintenant que tu le dis, effectivement ça saute aux yeux. Mais je préfère cette manière de faire, je me serais senti sale si j'avais utilisé un LEFT JOIN.

 
Et tu crois que tu sent la rose en utilisant oracle ?

C'est quoi ton problème avec left join?

J'ai pris une profonde inspiration hier et j'ai eu l'impression de me shooter à la coke
 

C'est juste dans ce cas de figure là, ça paraît trop illisible à mon goût si je passais par un join (accessoirement ça me rappelle mon TFE )

Ba après, c'est toujours le même pb des joins implicites : le relecteur n'est pas sûr de ce que ça fait vraiment et ça peut être problématique en termes de perfs si tu fais ce genre de trucs sur des grosses tables sans utiliser des clés/index corrects. Même si c'est plus verbeux, perso je préfère nettement l'explicite dans tout ce qui est SQL.

Ce sont de grosses tables et heureusement pour moi, il se trouve qu'il y a un index composite sur les champs qui m'intéressent.
 
Là je relis la requête (un brin plus complexe que ce que j'ai tapé plus haut mais c'était pour montrer l'idée), les perfs sont assez bonnes et j'avoue que je ne vois pas très bien comment je pourrais intégrer un JOIN là-dedans  En fait c'est surtout la partie derrière le MINUS qui m'inquiète parce que j'ai à nouveau une chiée de jointures et j'ai peur que ça devienne nettement moins lisible que maintenant  Les gens qui sont familiers avec l'application verront rapidement ce que je veux faire je pense.

Ba après, c'est typiquement le genre de truc qu'il faut demander aux DBAs. L'optimisation de requêtes complexes, c'est rare de trouver ça chez des devs.

On y compte bien Même si on a déjà SQL Optimizer à côté de SQL Navigator sur nos PCs

 
Ce serait dommage de devoir penser ensembliste après tout

'tain c'est plus ce que c'était le tiers-monde, ils ont l'ADSL dans le trou du cul de la Côte d'Ivoire

edit: à 30€ par mois comme ici

ouais mais 30€ par mois là-bas c'est hors de prix.

"ensembliste"?

regarde donc le EXPLAIN PLAN de ta requête avec jointure et celui de la requête sans, tu changeras d'avis ensuite

Pourquoi j'ai lu "juifs" à la place de "left join"

 
Ô racle ! Ô désespoir ! Ô Syntaxe ennemie !
N'ai-je donc tant codé que pour cette infamie ?
Et ne suis-je blanchi dans les travaux guerriers  
Que pour voir en un jour flétrir tant de lauriers ?

20 000 Francs CFA  

Ce type de reqûete (un IN au lieu d'un JOIN) c'est typique du dev qui fait du SQL et qui raisonne pas en algèbre relationnelle

Bigue kaibeule
http://www.flickr.com/photos/shutt [...] otostream/

Also

c'est complètement con comme remarque
un IN c'est un opérateur d'inclusion d'ensemble, c'est plus ensembliste que jamais et c'est même un des opérateur les plus pur du système (vu qu'il est ensembliste en général et pas simplement partie de l'algèbre relationnelle).
Il existe un special case en SQL pour ce type d'inclusion si on veut tirer les colonnes de la relation cible, mais ça n'a rien d'automatique et vouloir l'utiliser à tout prix. Peut être une volonté de convention de code etc. Mais ça ne remet absolument pas en cause une certaine "pureté" ou whatever de IN (ou de = , parce que je le sens venir aussi).
 
Je vous rappelle quand même que vous faites les beaux sur un langage qui n'a pas moyen d'associer un prédicat ou une projection à un label pour pouvoir le réutiliser plus tard, alors que ce sont 2 concepts essentiels de la théorie sous-jacente.

ouais, enfin là on parle d'un bled à 12h de route de la côte (soit hum, 600km ?)

 
T'as des SGBD qui pardonnent pas de mettre des IN (SELECT) vs un JOIN.

 
ACCESS

C'est de la faute du SGBD, pas de l'utilisateur. C'est strictement équivalent, ça doit être exécuté exactement de la même manière.

On a des SGBD qui l'implémentent de la même façon ?

Ca c'est la théorie.

c'est toi qui parlais de théorie (ensembliste) d'abord, nananère

bon, j'irai acheter mes cadeaux après le 21 décembre, pas la peine de s'emmerder avec des conneries si c'est la fin du monde hein

Pas con

nraynaud, dion, Harko, drasche, skeye, Taiche, stiffler, vapeur, uriel, boulax et même real moins moins!! (antp t'es ou?)
 
Nan mais vous êtes tous encore actifs sur ce forum malgré Facebook, Twitter, Stackoverflow, LinkedIn etc.. Et ça pose toujours des questions de jointures malgré NoSQL et tout.. truc
 
C'est foufou.. Vous êtes foufous les gars

Mais drapal quoi!