Discussion :

[e-youness85]

Bonjour tlm;

J'ai une basée de données d'une centaine de tables, avec l'attribut "identifiant" (différent de l'Id) en commun.
Ma question: comment on peut récupérer la valeur maximale de la colonne 'identifiant' .

Exp:
Table 1 Table 2 Table 3
identifiant Identifiant Identifiant
1 ............. 2................. 80
23............. 3 ................. 81
52........... 17..................102

Le max dans ce cas est : 102
Merci

[Fred_34]

Je ne pense pas qu'il y ai plus simple que de prendre le max de tous les max :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT MAX(identifiant) FROM (
SELECT MAX(identifiant) AS identifiant FROM table1
UNION
SELECT MAX(identifiant) AS identifiant FROM table2
UNION
SELECT MAX(identifiant) AS identifiant FROM table3
) t

Avec 100 tables ça commence à être lourd...

[FSiebert]

Votre modèle est très curieux
Quel peut être le besoin qui d'une part nécessite une centaine de tables ayant une colonne identifiant, et d'autre part nécessite de trouver le plus grand de ces identifiants ?

[e-youness85]

Merci à vous Fred_34 et FSiebert pour votre intérêt.
Pour la réponse de fred, c'est la solution que j'ai mis en place actuellement, mais en raison de l'importance de la base j'aimerais bien trouvé une solution miracle :p (de qlq ligne) qui me permettra d’alléger le code source.
Pour la remarque de FSiebert, effectivement je travail sur un gros projet.Et en ce moment, j'ai besoin de mettre en place des Triggers qui vont me permettre d'incrémenté "l'identifiant" à chaque insertion. Par contre ces triggers perrons être arrêtés avec une opération de l'utilisateur. Et au moment de la réactivation de ces triggers,j'ai besoin en effet de récupérer la valeur maximale de l'identifiant.
Merci

[FSiebert]

Utiliser des triggers pour mettre en place un auto-incrément me semble être une bien mauvaise idée.
Par ailleurs, quel peut-être l'utilité d'arrêter l'incrémentation d'un identifiant ?
Fonctionnellement, que représente cet identifiant ?

J'aimerai comprendre le besoin

[CinePhil]

Ce qui est en effet difficilement compréhensible sans plus de précisions, c'est le fait que les identifiants soient répartis dans plusieurs tables mais ne correspondent qu'à une seule séquence d'auto-incrémentation.

Dans un modèle de données normalisé, les entités types du MCD engendrent des tables chacune munies de leur propre identifiant auto-incrémenté et idnépendant des autres identifiants.
Si dans une BDD, j'ai des villes, des pays, des véhicules, des commandes, des factures, des livraisons... chacune de ces table aura un identifiant allant de 1 à N et peu importe qu'il y ait un 12 dans chaque table. Ces identifiants sont des clés techniques sans signification.

Votre problème est donc peut-être plutôt un problème de conception de votre BDD que de réalisation d'une requête SQL.

[FSiebert]

Ce qui est en effet difficilement compréhensible sans plus de précisions, c'est le fait que les identifiants soient répartis dans plusieurs tables mais ne correspondent qu'à une seule séquence d'auto-incrémentation.

J'ai une basée de données d'une centaine de tables, avec l'attribut "identifiant" (différent de l'Id) en commun.

Apparemment il y a bien un ID technique indépendant dans chaque table. Cet "identifiant" doit avoir une signification fonctionnelle quelconque mais j'ai du mal à saisir l'intérêt.

Sinon, j'approuve CinePhil

[StringBuilder]

J'imagine que cet "identifiant" peut par exemple servir de "version".

J'ai utilisé un système similaire pour synchroniser une base maître et des bases clientes, en utilisant le type "timestamp" de MS SQL Server, qui est un auto-incrément global à la base. Ceci me permettait d'isoler facilement, entre deux synchronisation, les lignes qui avaient été modifiés depuis la dernière synchro.

Dans le cas précis, je pense que le mieux, c'est de créer une SEQUENCE, et si MySQL ne supporte pas les séquences, en fabriquer une de toute pièce, en utilisant une table compteur et en écrivant deux fonctions "getCurrentValue" et "getNextValue".

Ainsi, les trigger sur les tables appelerons "getNextValue" pour récupérer la prochaine valeur, et dans les requête select, "getCurrentValue" pour connaître la valeur actuelle du compteur.

Ceci évitera d'aller lire des millions de lignes dans une centaine de table, mais plutôt une unique ligne dans une unique table, ce qui est quand même un peu plus optimisé.