Discussion :

[grab06]

Bonjour,

existe-t-il des modèles de base de données sans structure prédéfinies?

La structure des données est connue uniquement au niveau applicatif?

Au niveau de la base données, uniquement un embryon de structure générique existe. Par exemple, dans mon cas, j'ai une structure de base avec 4 tables

umt qui contient un champ "unique id" et un champ "key" (text)
umt qui contient un champ 'unique id" et un champ "value" (text)
ump qui contient un champ "unique id", un "umt(key)" et un "umt(value)"
ume qui contient un champ "unique id"
uma qui contient un "unique id, un "ume" et un "ump"

avec ça je peux créer toutes mes tables applicatives.

Savez-vous s'il existe des modèles de ce type?

[SQLpro]

Oui et sauf à utiliser un SGBD NoSQL de type PKV comme REDIS ou MEMCACHED, les performances seront catastrophique. Pour info, je suis intervenu chez un grand compte pour une base de données de ce type monté sur des tables relationnelles dans SQL Server et il y avait plusieurs dizaine de blocages total du serveur chaque jour et plusieurs milliers de deadlocks....
Après réglage du serveur (car impossible de modifier cette structure de merde...) on arrive à des performances acceptable, à médiocre, sans gros crash... Mais les utilisateurs sont mécontents, parce que les temps de réponse sont très longs, et du fait de la montée en charge il a fallut prévoir un serveur dont la RAM est égale à 2,5 fois la taille de la base (4 To de RAM...). Bonjour le coût... du fait du développeur débile qui avait pondu cela !!!!
De plus vous ne pourrez pas gérer l'intégrité référentielle et donc, la qualité de votre base sera pourrie. Il faudra passer fréquemment des rustines de corrections, sans que vous ne puissiez jamais garantir la cohérence des données.
Enfin, certains bon SGBDR (je passe sur MySQL ou PostGreSQL...) optimisent les requêtes en utilisant l'intégrité référentielle pour supprimer des jointures inutiles. Donc, en plus d'avoir une base pourrie, elle sera contre performante !

Qu'est ce qui vous gène dans le fait de devoir modéliser correctement une base ?
Que vous ne connaissez sans doute pas la puissance et la souplesse du modèle relationnelle... a mon humble avis, et que vous en avez peur...

Or une base de données c'est souple. On peut en modifier la structure à chaud sans problème et heureusement car les besoins en données changent constamment ! Soit parce que le métier évolue, soit du fait de nouvelles réglementations.
Il suffit d'avoir appris à modéliser correctement, et c'est un métier !

Pour info, mon collègue et amis Stéphane Faroult avait parfiatement dénoncé et expliqué cette absurdité né du cerveau de certains développeurs dans une vidéo qu'il à fait il y a près de 20 ans...

Vous verrez à partir de la minute 4 quel sera l'état de votre système en pratique !

A +

[grab06]

merci pour cette réponse argumentée d'une expérience réelle. C'est très très intéressant.

j'ai bien fais de poster dans le forum débutant :-)

ce qui me gène:

- mon manque de compétence dans ce domaine complexe des bases de données. pas la peur car c'est pour un projet perso qui touche un domaine qui me passionne et sur lequel je n'ai aucune contrainte.
- ma méconnaissance des mécanismes de modification de la structure de la base données à chaud, c'est je pense que c'est mon gros handicap, point bloquant.

j'utilise Django et son ORM couplé avec PostGreSQL

l'application est la suivante : cartopedia thématique (histoire de la seconde guerre mondiale) ... c'est à dire:
- porté sur une carte interactive et dynamique toute information historique géographique et temporelle relative à la thématique en question (par exemple, position des unités entre 1939 et 1945, libération des villes et villages, bombardements, action de résistances, stèles commémoratives ...)
- les utilisateurs entrent l'information. Du coup si un utilisateur veut entrer les infos sur un navire de guerre, il va créer la structure qui va avec, à savoir par exemple le type, le tonnage, la construction le lieux d'un naufrage, le capitaine ... Une fois entrée dans la base de donnée, d'autres utilisateurs pourront utiliser cette structure de donnée liée au navire de guerre.

D'ou le besoin d'avoir une structure de base de données très très modifiable à chaud ... !!!

Django avec son ORM n'est pas forcément la bonne approche, savez-vous quelle serait une meilleure approche?

merci à vous.

[grab06]

je viens de visualiser la vidéo, intéressant !!! Vraiment intéressant, j'avais en tête les problèmes qui y sont mentionnés CPU et accès mémoires, sans pouvoir les quantifier vu mon manque de connaissance dans le domaine. merci.

[SQLpro]

re,

merci pour cette réponse argumentée d'une expérience réelle. C'est très très intéressant.

j'ai bien fais de poster dans le forum débutant :-)

ce qui me gène:

- mon manque de compétence dans ce domaine complexe des bases de données. pas la peur car c'est pour un projet perso qui touche un domaine qui me passionne et sur lequel je n'ai aucune contrainte.

Alors, formez vous, ce n'est pas très compliqué. C'est de la logique...

- ma méconnaissance des mécanismes de modification de la structure de la base données à chaud, c'est je pense que c'est mon gros handicap, point bloquant.

Ultra simple... Il n'existe que trois commandes SQL pour ce faire : CREATE (création d'un objet), ALTER (modification d'un objet existant) et DROP (suppression d'un objet).

j'utilise Django et son ORM couplé avec PostGreSQL

L'utilisation d'un ORM est une grosse merde ! En effet cela va rapidement au début, si l'application est simple. A la fin, ça coute plus cher que d'avoir fait la chose sans. Et si la chose est compliquée, alors c'est la catastrophe. Ted Neward, lors de l'arrivée des ORM, avait qualifié cette race de soft de "vietnam de l'informatique..." !
A lire sur le sujet :
https://blogs.tedneward.com/post/the...puter-science/
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

l'application est la suivante : cartopedia thématique (histoire de la seconde guerre mondiale) ... c'est à dire:
- porté sur une carte interactive et dynamique toute information historique géographique et temporelle relative à la thématique en question (par exemple, position des unités entre 1939 et 1945, libération des villes et villages, bombardements, action de résistances, stèles commémoratives ...)
- les utilisateurs entrent l'information. Du coup si un utilisateur veut entrer les infos sur un navire de guerre, il va créer la structure...

CREATE TABLE (...)

...tout simplement ! qui va avec, à savoir par exemple le type, le tonnage, la construction le lieux d'un naufrage, le capitaine ... Une fois entrée dans la base de donnée, d'autres utilisateurs pourront utiliser cette structure de donnée liée au navire de guerre.

Dans un SGBD Relationnel tout est modifiable à chaud. Certaines modification nécessitent cependant un verrou, le temps de lancer la modif et ce verrous sera acquis lorsque les utilisateurs en train de manipuler ce même objet aurons terminé de l'utiliser. Pour la création, le seul verrou à poser est pour empêcher un autre utilisateur de créer un objet de même nom... Certains SGBDR haut de gamme (comme DB2, Oracle ou SQL Server...) acceptent la modification à chaud sans verrou (mode "ONINE") , mais cela nécessite des serveurs costaud, car il faut faire cohabiter l'ancienne version avec les utilisateurs qui avait commencé de scruter l'objet avant la demande de modif et la modification en live de l'objet...

D'ou le besoin d'avoir une structure de base de données très très modifiable à chaud ... !!!

Django avec son ORM n'est pas forcément la bonne approche, savez-vous quelle serait une meilleure approche?

merci à vous.

Développer à l'ancienne, en mode générique plutôt qu'objet !

En plus je voit que vous partez sur PostGreSQL dont les performances sont assez moyenne...Pour ne pas dire catastrophique dans certains cas comme exposés ici :
https://sqlpro.developpez.com/tutori...ndes-pour-dba/
https://sqlpro.developpez.com/tutori...es-avec-count/

A +

[grab06]

Bonjour, merci pour vos réponses.

Votre style, plus que direct, m'a un peu perturbé au départ, mais au final, je crois que j'ai collecté plus d'informations sur les base de données en un seul post que tout le temps que j'y ai passé tout seul. Je n'aurais jamais trouvé seul la vidéo de Stéphane Faroult !!!

Je vais parcourir les liens que vous avez pointés et reconsidérer mon approche et mes choix ... et si d'autres personnes ont des avis complémentaires ou divergents, je serais très preneur de leurs points de vue. C'est très enrichissant.

Bonne journée à vous.

[SQLpro]

pas de quoi... Mais il faut farfouiller. Le problème des moteurs de recherche c'est qu'il indexent les documents par popularité plus que par leur qualité.

Il y a quelques années dans une boite ou les développeurs n'avaient pas de formation professionnelle et devait tout apprendre sur Internet, et ou le code avait complétement dérivé, j'avais écrit dans mon audit, texto :

"
lorsque les développeurs n'ont comme source d'apprentissage que le web qui indexe, non, par pertinence, mais par popularité, les sujets exposés, on ne doit pas être étonné que ces mêmes personnes s'intéressent donc plus aux poils de cul de Paris Hilton qu'à la philosophie de Marx ou d'Engels !
"
Quelques temps après, le PDG m'avait appelé au téléphone et viré son directeur technique...

A +