Nettoyage colonne et table non utilisées

Bonjour,

Existe-t-il une fonctionnalité de nettoyage des tables et colonnes non utilisées ? ou cela est-il prévu pour la V6 ?

Le besoin revient assez souvent, dans le but de conserver une BDD propre sur les instances ou des tests sont effectués (création d’objets et d’attributs non utilisés dans le futur).

Merci d’avance,

Benoît

Technical information

Instance /health
[Platform]
Status=OK
Version=5.3.24
BuiltOn=2023-12-07 15:59
Git=5.3/29fe55f389cbc517e57851b84b9146b315b93982
Encoding=UTF-8
EndpointIP=xxx
EndpointURL=xxx
TimeZone=Europe/Paris
SystemDate=2023-12-19 10:17:52

Bonjour

J’ai passé le post en feature request mais plutôt pour des outils d’aide à l’identification des choses potentiellement supprimables.

En effet, dans le cas général, à fortiori en dev où on modifie beaucoup de choses en permanence, c’est toujours risqué d’effectuer des suppressions physique sans laisser faire l’analyse préalable par un humain de la pertinence de ces suppressions.

Perso j’utilise des requetes SQL du genre de celle là (ici vérif - sur HSQLDB - des tables existantes en base vs les tables associées à des objets métier simples pour un pattern de nommage donné (ici tables préfixées DEMO_):

select table_name
from information_schema.system_tables
where table_name like 'DEMO_%'
and table_name not in (
    select distinct upper(obj_dbtable)
    from m_object
    where obj_dbtable like 'DEMO_%'
)
order by table_name;

Mais cette requête fera, par exemple, ressortir des tables utilisées uniquement par des objets “select”, ce qui peut être un pb sans analyse plus poussée.

1 Like

Merci pour la réponse @david. L’idéal serait de pouvoir avoir un listing table et colonne non utilisées pour pouvoir donner les droits à un Admin de l’application pour qu’il puisse faire un nettoyage si nécessaire de temps en temps.

Oui c’est le sens de ma réponse = fournir un outil d’audit pour proposer et aider à statuer sur des actions manuelles à effectuer après analyse. Sachant qu’en attendant qu’il est déjà possible de le faire via des requêtes SQL.

J’insiste sur la fait que, comme dit plus haut, cette approche basique ne prend pas en compte le cas des objets “select”. Cela dit, ceux-ci ne portent généralement pas sur des tables qui ne sont pas aussi utilisées par des objets métier simples mais le cas peut se présenter (par exemple, dans le cas d’ “intégration” de tables issues de bases de données tierces par un mécanisme SGBD bas niveau genre via DB link Oracle)

1 Like

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.