Discussion :

[xavier.ninane]

Bonjour,

Je pose cette question sur ce forum, mais je pense qu'elle pourrait être posée également sur les autres relatifs aux SGBD.

Mon application (pour mon business) est développée avec Windev

J'utilise leur SGBD (HFSQL) en C/S.
Je ne me plains pas : ça fait son job dans le cadre de mes besoins.

J'envisage de faire migrer l'outil vers une autre plate-forme et j'analyse la faisabilité notamment en regard du modèle de données.

Je crois comprendre que Windev offre une singularité qui n'existe pas ailleurs : la possibilité d'avoir des sous-répertoires (physiques) dans la BD. Et donc, de stocker des table de même nom, mais à des endroits différents.
Ce mécanisme, semble-t-il fort mécréant, m'est bien utile : mon application est de type comptable : multi-société, multi-exercices.

Je vous mets l'image de l'organisation de la BD



Pour avoir débuté sur Access, je sais que cette organisation des tables y est impossible.
En me documentant sur SQL-SERVER (mais aussi sur PostgresSql), j'ai la nette impression que cette notion de répertoires n'y existe pas non plus...
Me le confirmez-vous (en tout état de cause pour SQL-SERVER) ?

D'avance merci.

X.

[aieeeuuuuu]

Bonjour,

En effet, cette notion n'existe pas dans SQL Server.

En revanche, vous avez la notion de SCHEMA, qui permet ce découpage par domaine, mais il n'est pas possible de les imbriquer

[xavier.ninane]

Merci.

[StringBuilder]

Même si la question est marquée comme résolue, j'apporte mon grain de sable.

Je ne pense pas que les schémas soient spécialement adaptés au besoin (puisque non empilables).
Accessoirement, cela rendra les requêtes d'analyse/édition complexes si on tape dans de multiples schémas pour comparer des données d'un exercice à un autre entre diverses sociétés.

Pour moi, l'ensemble de ces "répertoires" sont des données en tant que tel.

Toutes les tables qui se trouvent dans le dossier "2015" par exemple devraient avoir une colonne "Exercice", remplie avec la valeur "2015".
Ainsi, on peut y rajouter aussi les données de l'exercice 2014 en remplissant alors la colonne avec 2014.

Dans toutes les requêtes alors, au lieu de préfixer la table par l'année d'exercice, il suffit de filtrer sur la colonne créée.

On fera pareil pour tous les répertoires et tous les niveaux.

L'avantage, c'est que si demain du veux travailler sur plusieurs exercices à la fois, et/ou plusieurs sociétés à la fois, tu as juste à modifier le filtre, plutôt que de faire de multiples requêtes et des traitements lourds en mémoire.

[xavier.ninane]

Merci StringBuilder

J'ai effectivement réfléchi à le remodélisation qui devrait effectuée pour tenir compte de la spécificité en arborescence actuellement en vigueur.

De fait, chaque table dans chaque répertoire, est une table à part entière qui devrait donc être nommée différemment. C'est comme ça que je l'envisageais.
Et en même temps, ce sera une torture au niveau du code sql qui devra être construit dynamiquement en fonction des exercices et sociétés concernés.

L'autre solution que tu suggères est certainement la plus élégante, même si dans l'application métier, les analyses inter-sociétés ou inter-exercices ne sont pas une demande.

Je continue à réfléchir, car je mène ce projet de bout en bout en bout, et que le codage SQL n'est vraiment pas un domaine que je domine.

La migration vers SQL Server (ou PostGres) ne se fera que si je migre en parallèle vers VisualStudio : les performances du C/S de PCSoft me donnent parfaite satisfaction dans le contexte métier.

[SQLpro]

Le moyen le plus simple est de créer des vues et d'utiliser les vues pour faire les mises à jour filtrées par ce que l'on veut.

Ne jamais oublier que l'on peut faire des INSERT, UPDATE, DELETE dans les vues.

A +

[aieeeuuuuu]

Tout à fait

Et sous SQL Server, vous pouvez spécifier l'option WITH CHECK OPTION dans les vues. Ceci vous évitera que le client client X puisse insérer des données pour le client Y.

[escartefigue]

D'accord avec stringbuilder, j'ajouterai juste que l'on peut partitionner sur l'année pour faciliter l'archivage et optimiser les performances

[StringBuilder]

Ouais enfin le partitionnement c'est pour la version Entreprise.

Vu le besoin (et la tentative initiale d'utiliser Access) je pense qu'on est plutôt sur du Standard voir même du Express