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 ...

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

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 ...

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.

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

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.

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 ....