Discussion :

[DreamNooby]

bonjour à tous !

je ne comprends pas certaines choses en rapport avec les bases de données...


1) sur pas mal de sites on trouve par exemple :
- la possibilité d'entrer plusieurs adresses de livraison (j'ai essaye au moins plus de 8)
- de conserver toutes les factures des clients pour qu'ils puissent y acceder intantanément même des années plus tard.

Je me demande comment ils peuvent gérer ce genre de choses au niveau de l'organisation de "la base de données" ?

Pour dire simple je ne comprends pas grosso-modo comment la base est "structurée et gérée" au niveau de ce genre de données : je vais exagérer en disant que "généralement on ne crée pas une base par client"... ??


Quel est le meilleur compromis parce que si c'est lent ce n'est pas bien et si il faut une machine costaud ça coute... en plus si l'architecture s'écroule lors d'une montée en charge c'est la catastrophe !


2) En rapport avec la question 1 : en GNU/Linux sous un 'LAMP', j'envisageais de développer en PHP / MySQL ... mais avec tout ce que j'ai lu je ne suis plus certain que cela soit un bon choix dans le temps...

Quel SGBD choisir ??? MySQL - PostgreSQL - Firebird/Interbase ???

mon projet serait tourné vers du e-commerce et/ou de la messagerie, alors quelle est la base de donnée qui serait la plus appropriée ?


3) Par la suite, pour l'exploitation, si le site est hébergé chez un "herbergeur" (pour raisons de securité : chacun son metier) cela peut poser des problèmes par rapport au choix d'une base de donnée que ce dernier ne connaitrai pas... sans compter l'acces a cette même base de donnée qui devrait se faire a distance (ce n'est pas dit que cela serait facile à gérer surtout pour une mise à jour).

Pour dire vrai je suis un peu perdu à me décider

Merci

[SQLpro]

1) sur pas mal de sites on trouve par exemple :
- la possibilité d'entrer plusieurs adresses de livraison (j'ai essaye au moins plus de 8)

A l'infini si la base est bien modélisée. Imaginons que vous changez d'adresse tous les 3 jours... Il n'y a donc aucune raison de limiter le nombre d'adresse à une quelconque valeur. C'est d'ailleurs tout l'intérêt des bases de données.

- de conserver toutes les factures des clients pour qu'ils puissent y acceder intantanément même des années plus tard.

Heureusement ! Une BD doit permettre au moins 10 années d'historique puisque légalement c'est obligatoire...

Je me demande comment ils peuvent gérer ce genre de choses au niveau de l'organisation de "la base de données" ?

En faisant une base bien modélisée, c'est à dire en respectant la théorie de la normalisation afin d'établir des modèles de données qui soient repectueux à la fois des concepts et des règles de l'art.

je vais exagérer en disant que "généralement on ne crée par une base par client"... ??

Jamais ! Une base de données doit pouvoir traiter des centaines de milliers de client des millions de factures des dizaines de millions de lignes de commandes... Et même la comptabilité de tout cela...

Quel est le meilleur compromis parce que si c'est lent ce n'est pas bien et si il faut une machine costaud ça coute... en plus si l'architecture s'écroule lors d'une montée en charge c'est la catastrophe !

La voila la bonne question. Oui pour conserver une telle masse de données il faut une bonne machine. Certaines bases de données dépassent aujourd'hui 100 Téra octets. Cela signifie qu'il faut au moins 300 disques au serveur pour servir une telle quantité de données (et même techniquement beaucoup plus...). Malgré tout les temps de réponse seront bon, si la base a été bien modélisée et si le serveur a été bien dimensionné.

2) En rapport avec la question 1 : en GNU/Linux sous un 'LAMP', j'envisageais de développer en PHP / MySQL ... mais avec tout ce que j'ai lu je ne suis plus certain que cela soit un bon choix dans le temps...

PHP / MySQL n'est pas un mauvais choix pour des base pas très importante et peu transactionnelles.
Si la base de données va être importante et avec beaucoup d'utilisateurs faisant de nombreuses transactions, alors il faut aller un cran au dessus : PostGreSQL voir Oracle.

mon projet serait tourné vers du e-commerce et/ou de la messagerie, alors quelle est la base de donnée qui serait la plus appropriée ?

Tout dépend du volume des données et des transactions :

• base de 1 Go, 10 Go, 100 Go ?
• utilisateurs simultanés : 10, 100, 1000... 10 000 ?

tant que vous n'aurez pas dimensionné votre projet le choix ne peut être fait !

3) Par la suite, pour l'exploitation, si le site est hébergé chez un "herbergeur" (pour raisons de securité : chacun son metier) cela peut poser des problèmes par rapport au choix d'une base de donnée que ce dernier ne connaitrai pas... sans compter l'acces a cette même base de donnée qui devrait se faire a distance (ce n'est pas dit que cela serait facile à gérer surtout pour une mise à jour).

Si votre projet est de, faible dimension, alors vous trouverez toujours un hébergeur capable de faire un minimum d'admin. Si votre projet est de grande envergure, vous devez envisager un modèle économique plus serrer et peut être embaucher un DBA (Administrateur de base de données).

A +

[DreamNooby]

hello

Merci pour toutes ces réponses

J'avais effectivement aussi consience des obligations légales... (c'était aussi une question technique).

Dans mon cas vu que c'est du web, pour le volume des données et des transactions, ce n'est pas tres previsible... ce n'est pas au moment où tout serait saturé qu'il faudrait se demander si il aurait fallu du prevoir plus large. Je prefere prevoir une infrasture suffisante (dans la mesure du possible).

Mais vu aussi que j'ai plusieurs idées en tête je préfére avoir un "19tonnes plutot qu'un express", si on a l'habitude d'un produit qui sait s'adapter alors ça va. Le SGBD est genéralement le coeur de tout systeme d'information, donc j'aimerai mieux éviter de négliger ce point d'importance


MySQL qui est sympa, mais semble montrer ses limites fonctionnelles et risquerait de s'ecrouler : des sites ont du faire des changements radicaux au bout de quelques temps.


Oracle semble etre un peu "excessif" a tous les niveau, j'envisage peut-être de me tourner vers Firebird ou plutot vers sa version Interbase (mais reste a savoir s'il vaut mieux l'un ou l'autre... "s'ils semblent un bon choix").


J'aimerai plutot réaliser le projet en bossant moi même dessus, au moins dans un premier temps ne serait-ce que pour essayer d'apprendre un certain 'savoir-faire' puis éventuellement de faire valider mon travail, surtout si je rame trop. De tout façon il est fort a parier, surtout si cela marche fort qu'un DBA a un moment ou a un autre ne sera certainement pas du luxe pour m'aider à formaliser tout ça et à maintenir l'ensemble... mais tout est une question de moyens lol.

En faisant une base bien modélisée, c'est à dire en respectant la théorie de la normalisation afin d'établir des modèles de données qui soient repectueux à la fois des concepts et des règles de l'art (DBA).

Il est certain que rien ne remplace l'expérience d'un domaine précis.

J'aimerai bien heberger moi-même, mais bon c'est tres couteux et puis au niveau securité c'est un métier, donc dans un premier temps c'est plus un reve qu'une réalité, alors cela sera certainement un hebergeur (reste a savoir s'il acceptera le type de SGBD choisi).

Merci !!

[DreamNooby]

Hello...

je me permets de revenir sur ma première question avec l'histoire de stocker plusieurs adresses de livraison...


Si l'on a un utlisateur qui a une ID alors je suppose que l'on doit :

- Creer une relation entre une ID qui designe une adresse et l'ID de cette utilisateur
- si on a d'autres adresses, je suppose alors que l'on doit créer une relation de ce genre :


ID utilisateur 1 + ID Adresse 1 = Première adresse
ID utilisateur 1 + ID Adresse 2 = Deuxième adresse
ID utilisateur 2 + ID Adresse 3 = Première adresse utilisateur 2
ID utilisateur 2 + ID Adresse 4 = Deuxième adresse utilisateur 2

je vais peut-etre dire quelque chose d'idiot, mais dans une base de données les données qui y sont stockées sont bien stockées selon leur ordre d'arrivée sauf s'il y a une fonction de tri.

est-ce que ce que je dis n'est pas n'importe quoi ?

Merci

[orafrance]

Non, il n'y a pas d'ordre de stockage... une table est un sac de bille, c'est à l'extraction des données (le SELECT en somme ) que tu imposes éventuellement un ordre.

[DreamNooby]

Merci pour ta réponse

Il va falloir que je travaille tous ces points lol

Je crois que j'ai du boulot !

[SQLpro]

Pour une adresse (et pour bien d'autres choses) vous pouvez rajouter une information d'importance : adresse par défaut, ou typage : adresse de livraisons, facturation....

A +