exemple de base non-relationnelle ?

Les bases de données fichiers qui existaient avant le developpement des bases de données relationnelles et qui tournaient sous DBASE par exemple.
Bases où la séparation des structures uniques n'est pas prise en concidération et où la redondonce des données et la ressaisie abondent. Mais aussi l'incohérence entre les données qui identifient les mêmes individus.
Par exemple, les données client sont saisies dans une fiche client et sont ressaisies dans le bon de commande. On risque d'avoir une identité de client douteuse dù aux différences des données dans la fiche client et sa commande sans parler des autres supports concernant le client à savoir le bon de livraison, la facture, les bons de poaiement, les relances ....

Puisque ça t'interesse,
Une BDD est dite relationnelle si conceptuellement parlant, elle respecte les règles de la conception relationnelle et répond à l'application des lois de l'algèbre relationnelle.
Le concept relationnel dit:

* Une entité est un regroupement d'attributs (ou propriétés) identifiant un individu pour le différencier de son environnement (ex. l'identité d'un client est indépendante de celle d'un produit)

* Une entité est identifiée dans son environnement par un identifiant composé de un ou plusieurs de ses attributs (ex. une entité "client" peut être identifiée par son n° ou à défaut par son nom+prénom+date de naissance ou par son email... c'est un choix de l'analyste)

* La mission de l'identifiant n'est pas seulement d'identifier l'entité dans son environnement par rapport à d'autre entités mais aussi d'organiser un système d'accès unique aux occurences (multiplicité fonctionnelle) (que l'entité stockera dans le modèle physique même si ce n'est pas la priorité du concepteur).

* Les entités dans un système d'information se croisent entre elles pour produire des associations. Ce sont ces dernières qui représentent l'architecture relationnelle du système.

* Une association est créée par les traitements que les entités subissent.
une association est liée aux entités qui contibuent dans la création de ses occurences par des liens de dépendance. On dit que ce sont des liaisons fonctionnelles et sont de 3 types :
1. liaison fonctionnelle forte de type (1..1) où une entité à besoin de la présence de l'autre entité pour créer une association
2. liaison fonctionnelle faible (0..1) qui est l'inverse, c'est à dire qu'une entité n'est pas obligée de respecter l'association avec autrui. Le degré de dépendance est très faible
3. liaison fonctionnelles (N) dont les dépondences des occurences peuvent être faibles ou fortes

ex:
Un produit commandé et non livré n'est pas facturé : ceci veut dire que la commande qui est née par l'association entre client et produit n'exige pas la présence d'une facture : de ce fait le lien entre la commande et le client est fort par contre celui entre la commande et la facture est faible

Représentation:
1. Client --- N ---> Commande (lien multiple)
2. Commande --- 1..1 ---> Client (lien fort = DFF (dépendance fonctionnelle Forte))

Dans (1) Le client est un accès aux groupes de commandes lui appartenant
Dans (2) La commande est spécifique à un client

Si on prend le traitement de gestion des commandes
Dans (1) les commandes (N) complètent l'information fonctionnelle d'un client donné
Dans (2) le client complète l'information fonctionnelle d'une commande donnée

Ces liens fonctionnelles qui permettent de complèter l'information dynamiquement sans devoir la ressaisir pour chaque entité sont appellés des relations fonctionnelles. pour assurer leurs intégrité et cohérence on les observe par des contraintes d'intégrité dites référencielles ou fonctionnelles

les liens N et 1..1 sont à observer au niveau des changement d'états des occurences pour s'assurer que l'association soit correcte.

L'algèbre relationnelle (ensembliste) sur la quelle se repose SQL permet justement de mettre en place ses règles de fonctionnement.

je viens d'éditer le titre et le post toutefois si vous voulez continuez de partager vos connaissances ou vos recommendations sur les bonne pratiques de fonctionnements des BDD n'hesitez pas je suis sure que ca fera du bien a pas mal de monde.
Cependant les points abrodés tout au long de ce sujet m'ont donner quelques axes de réflexion que j'espere mettre en pratique le plus rapidement possible.
Cordialement

Alors effectivement, si tu utilises une base de données SQLServer, il est plus logique généralement de travailler en ASP.

Tu devrais d'ailler éditer ton premier post et corriger le titre.

tout d'abord je vous prie de bien vouloir m'excuser pour mes abus de langage : je ne parlais pas de SQL mais SQL serveur.
Toutefois je vous remercie tous pour vos réactions fort intéressante.
Les axes ainsi que les problématiques soulevés sont tout à fait judicieuses à savoir la confusion entre PHP et MySQL ( disons que l'on pense que l'un et l'autre font parti d'un même tout).
De plus la non maîtrise des bases des BDD est un fort problème.
Je le persoit d'autant plus que me spécialisant dans le PHP j'en oublie les fondement du fonctionnement d'une BDD (ce qui est fort regrettable).
La "simplicité" de fonctionnement de MySQL n'est pas étrangère a cette mise de coté (pour ma part ) de ce qui fait qu'une base est une base ( MCD MLD etc ...) soit une réflexion sur l'optimisation sur la conception et la sécurité des bases.
Ce rappelle à l'ordre que vous faite me semble plus que nécessaire et je vous en remercie ...

Je développe autour de SQL Server en PHP, ça marche bien. L'inconvénient d'asp, c'est la rareté des personnes bien formées, donc le prix (si on va à fond dans le .Net ) et les formations à prévoir.

Je ne suis pas convaincu de la rareté des personnes bien formées à l'utilisation de l'ASP sinon j'aurai déjà du retrouver du travail.

hu hu, je vais te filer les coordonnées de mon chef!

A+

Pascal

De plus, la notions d'intégrité référentielle commence à prendre un sens important lorsque le développeur commence à penser optimisation, sécurité, stabilité

ET malheureusement, c'est pas une notion assimilable facilement ...

Comme le PHP est un langage qui attire beaucoup d'auto didacte, je pense pouvoir dresser une lien de causalité

Je ne suis pas sur que ce soit le langage en lui même qui attire mais plutôt le mot gratuit.

En fait les débutants ne débutent pas vraiment, ils se permettent de penser que "réussir à cuisiner leur premier plat est de savoir servir un plat déjà cuisiné"
Un novice qui décide d'écrire en PHP le confond à HTML et JS, croit que Mysql fait partie de PHP, qu'une base de données est une table et que les contraintes d'intégrités référencielles n'existent pas puisque Mysql dans ses premières versions ne les incluait pas.

Aucun débutant ne prend la peine de savoir que les bases de données sont d'abord issues d'une analyse conceptuelle de données et de traitement et veut programmer sans connaitre les méthodes et les règles qui régissent.

Pour abonder dans le sens de pjl, l'abscence de contraites d'intégrité référentielles facilite la prise en mains par les débutants.

Comme le PHP est un langage qui attire beaucoup d'auto didacte, je pense pouvoir dresser une lien de causalité

D'ailleurs, en 98, on ne parlais quasiment pas de MySQL dans le monde de Linux. c'était Postgress qui était à l'honneur.

Personellement, je suis persuadé que ce qe qui a fait le succès de MySQL est son principal défaut : l'absence de gestion des contraintes d'intégrité en mode natif :
- necessite moins de ressource serveur, donc on peut mettre plus de base sur une même machine pour un coût identique ;
- moins de support client : comme c'est le dev qui doit les gérer, ben s'il oublie de le faire ou s'il le fait mal, ca passe inapercu dans 99% des cas.
imaginon un cas classique :
3 tables :
une table voiture
une table couleur
une table voiture_couleur ayant comme clefs étrangères l'id de voiture et l'id de couleur.
Si je décide de suprimer une couleur alors que j'ai encore des voitures de cette couleur en stock, avec MySQL, je peux le faire sans problème et il y a de forte chance que personne ne se rende compte de l'erreur.

PostgreSQL est un SGBDR fonctionnant sur des systèmes de type UNIX par exemple Linux, FreeBSD, AIX, HP-UX, IRIX, Solaris, ...
Issu de la famille de logiciel libre, sa méconnaissance est dûe à un problème marketing ce qui ne diminue pas de ses qualités.

Oracle intègre la plateforme JAVA mais JAVA peut être dédié à n'importe quel SGBDR y compris SQL SERVER.

Oracle et JAVA : http://www.oracle.com/technology/tech/java/index.html
Oracle et .NET : http://www.oracle.com/technology/tech/dotnet/index.html

En traçant l'historique de Oracle on voit que Oracle a était toujours le partenaire de JAVA. Mais sa concurrence avec IBM et MICROSOFT fait que de nouvelles ouvertures techniques se développe pour percer le marché.

Je développe autour de SQL Server en PHP, ça marche bien. L'inconvénient d'asp, c'est la rareté des personnes bien formées, donc le prix (si on va à fond dans le .Net ) et les formations à prévoir.

Je ne suis pas convaincu de la rareté des personnes bien formées à l'utilisation de l'ASP sinon j'aurai déjà du retrouver du travail.

En relisant ton post, j'ai compris que tu montrais 3 exemples. j'avais mal lu

Sinon, le peu d'application JAVA que j'ai vu de près tournais avec SQL Server, pas avec Oracle

Est-ce que c'est comme PostGreSql en PHP, utilisable, performant mais pas aussi répendu que MySQL ?