De plus, je ne recherche jamais (ou presque) un enregistrement par des critères divers mais uniquement par son type, qui renvoit à une table, et son identifiant qui sont tout deux connus.
Inversement, je ne connais jamais ni le nombre ni le type des enfants d’un élément. Le bon sens peut limiter à un maximum de 20 photos par diaporama, et à 8 enfants pour les autres éléments.
Pour chaque élément pouvant avoir des enfants, une colonne enfs code le type d’enfant et son identifiant dans une chaine du type B1324 B3443 C3423 I43554 etc,
1 lettre pour définir la table de l’enfant, 8 chiffres pour l’ identifiant et un séparateur entre chaque enfant.
Ceci correspond à la version 1 de la BDD.

Pour la version 2 de la BDD, j’ai fais avec une table de liaison mais alors, il me fallait préciser l’ordre des éléments enfant dans son parent (version 2) :
type_parent id_parent type_enfant id_enfant ordre
C(sequence) 23345 B(séance) 1324 1
C(sequence) 23345 B(séance) 3443 2
C(sequence) 23345 C(séance) 3423 3
C(sequence) 23345 I(séance) 43554 4

Et chacun des éléments en ligne ci-dessus pouvait à son tour avoir d’autres enfants… Et définitive, cette table peut vite compter des milliards de ligne et devrait être lue 12 fois pour l’arborescence présentée ci-dessus.
J’ai fait un test des deux structures de base de donné avec 200 000 lignes parent ou enfants et une table de liaison de 400 000 lignes.
La version 1 était presque deux fois plus rapide que la version 2 sur serveur en ligne.
Je précise aussi qu’un seul utilisateur (le prof) peut modifier un enregistrement et qu’au maximum, 400 élèves consulteront un même cours.
Cette base est donc particulière car certains éléments comme le contenu du cours exige une colonne de 4000 octets et qu’avec 10000 profs, il peut y avoir 10 millions de lignes avec ce type de contenu.
Mon inquiétude est dans le risque de lenteur pour un prof ou un élève.
Pour y pallier, le serveur n’envoie hormis le texte du contenu, que des informations codées avec un minimum de html, le javascript s’occupe de l’affichage.
Avez-vous un avis sur cette base et si cela est mauvais, des pistes d’amélioration ?
Cordialement

Est-ce que dans ce genre de situations l’héritage de table (disponible dans PostgreSQL) ne rend pas encore plus simple la mise en place d’un modèle spécifique ?

Bien Cordialement

Merci pour ce billet.

Cependant je trouve que certains aspect ne sont pas couvert par celui-ci. En conséquence de quoi, il ne peux être une réponse absolue à cette problématique de modélisation / conception.

Je m’explique, la solution préconisée ici présuppose un modèle figé dans le temps, sans ajout de critère, ce qui peut poser un problème d’usage de l’outil qui s’appuiera sur un tel modèle. Vous me direz qu’il est tout à fait possible d’ajouter une colonne à la table cible par le biais de ce même outils, mais nous créons alors un problème de qualification de la données en déléguant à l’utilisateur final une opération dont il ne maîtrise pas, à priori, les tenants et aboutissants.

En sommes, la solution n’est pas aussi simple que vous semblez le décrire en restant essentiellement sur la théorie des modèles, là où ce que vous appelez, avec peu de courtoisie, développeur incultes affirmant n’importe quoi, par ignorance, ou par bêtise, sont confronté à la vie concrète, et que les entreprises essentiellement TPE / PME n’ont pas les moyens d’avoir un informaticien à demeure.

Pour conclure, je pense que le constat est bon que la réponse apporté est bien sur valable pour ce cas précis et dans la théorie des modèles, mais qu’il n’apporte pas une réponse complète à la problématique qu’il prétend résoudre.

Dans l’attente de vous lire,
Cordialement

A +