Yvanoph Karim Modérateur ABC du Web Karim Yvanoph WebMaster 3Alannet webmaster@abc-du-web.com BP 116 7080 Menzel JEMIL Gouvernorat de BIZERTE Tunisie Yvanoph www.abc-du-web.com 0021625332209
Retour à l'Accueil du Mode d'Emploi du Forum XWebDesignor ?
   Accueil   Aide Rechercher Tags Identifiez-vous Inscrivez-vous  
Pages: [1]   Bas de page
  Imprimer  
Auteur Fil de discussion: Base de données, données de base de leur gestion !  (Lu 2407 fois)
yvanoph
Administrator
Hero Member
*****
Hors ligne Hors ligne

Messages: 2 818


Le PIRE des défauts, ne pas RECONNAÎTRE une erreur


Voir le profil WWW
« le: Mar. 21 Octobre 2014 à 16:29:42 »

Une base de données, comme son nom l'indique, n'est jamais qu'un ensemble contenant des données ! L'ensemble peut être construit par plusieurs moyens, et donc porter plusieurs noms ou extensions, selon le moyen utilisé ? Mais cela revient toujours au même quant à la construction, et ensuite l'exploitation...


Les données, quant à elles, peuvent être de plusieurs ordres, ou Catégories, ces dernières contenant elles mêmes plusieurs types ? Mais un exemple parlant mieux qu'un long discours, prenons le cas courant d'une gestion commerciale élémentaire, et, pour être plus pratique, celle précisément d'un annuaire de C.H.R. ?

Nous aurons au moins deux ordres ou Catégories de données à gérer, en premier lieu les Articles, en deuxième lieu, éventuellement des Clients ! Voire ultérieurement des Commandes, et donc des Factures et Encaissements ?


Dans la pratique courante, cela sera matérialisé dans notre bureau par une Armoire, contenant des Classeurs, ces derniers contenant des Intercalaires puis des feuilles, n'est-ce pas ? Chaque feuille contenant liste de renseignements, peu ou prou correctement ordonnés, alignés, rangés, classés, sur chaque C.H.R., ou Client, voire carrément étant une Facture ?
L'Armoire, c'est donc notre ensemble de Bases de Données, les Classeurs nos Bases de Données, les Intercalaires nos Catégories, les Feuilles nos données, Caractéristiques par Articles, Clients etc. !

Transposé dans un Ordinateur, ce sera un /Répertoire qui représentera l'Armoire, lequel contiendra des Classeurs sous Excel, soit des fichiers doté d'une extension précise selon la Version du programme utilisé, les dits Classeurs contenant des Feuilles, soit nos Intercalaires représentant les Catégories, chaque ligne contenu dans chaque Feuille représentant un Article, ou Client, ou Facture etc., sous réserve bien sûr de ne pas mélanger Articles, Clients etc. dans la MÊME Feuille ? ? ?

Pour reprendre l'exemple des C.H.R., nous avions même opté pour un Tri selon quelques critères, à savoir une Feuille/Catégorie pour les Hôtels et UNIQUEMENT ces derniers puisque n'ayant rien à voir avec les Campings par exemple ? De même que les Restaurants, totalement différents des deux Catégories évoquées précédemment, le seul point commun ultérieur pouvant être d'avoir les mêmes Clients...

A ce niveau là, vous devez, je pense ... et ose même fortement espérer, vous devez donc commencer à comprendre toute la subtilité à organiser, gérer, trier ses données, voire les nuances, différences à considérer entre chaque type de données ?
Car prendre un tas de Feuilles papier chez vous, les perforer puis les jeter dans un Classeur, certes, vos données seront regroupées, mais quant à en retrouver une précisément dans le tas, je vous laisse imaginer le temps nécessaire sans parler de l'énervement ou même pour un "professionnel" de l'image de marque présentée ?
De même, vous en déduirez de suite qu'une BONNE Base de données est donc issue du BON SENS, du niveau d'intelligence et capacités de raisonnement de son créateur... Ce qui n'a donc STRICTEMENT RIEN à voir avec l'informatique, n'est-ce pas ?


Une fois compris la méthode de tri et de gestion à appliquer à vos données, rien de plus facile que créer les colonnes dans chacune de vos Feuilles Excel, voire même de leur ajouter des attributs spécifiques obligatoires ou non, genre Case obligatoirement pleine, ou uniquement remplie de chiffres, voire même limitée en taille, pour exemple un Code Postal (Exemple NON valable pour tous les pays d'ailleurs...) ou un Téléphone ? Là ENCORE, selon le niveau de réflexion du créateur, ça marchera pour tout le monde ... ou PAS ! ! ! Pour exemple le Module E-Commerce dans XWebDesignor, qui n'autorise QUE des pourcentages ou décimales à deux chiffres après la virgule, alors que certains pays travaillent avec des Millimes et des pourcentages donc à TROIS chiffres après la virgule... Ce qui nous démontre bien évidemment une méconnaissance totale du Monde de la part de son créateur ? Car aller traîner ses chaussures et valises dans n'importe quel pays ne prouve pas du tout une assimilation des habitudes et coutumes locales, car là il s'agit d'une démarche de recherche personnelle que n'ont pas, tant s'en faut, la majorité des touristes qui restent plus frimeurs que intéressés réellement par autrui ?

Pour en revenir à nos données, il conviendra aussi pour chaque ligne d'enregistrement d'attribuer un identifiant unique, en principe un index numérique, qui s'incrémentera automatiquement à chaque ajout d'une ligne ? Un peu comme chacun son numéro de Sécurité Sociale (Enfin ... théoriquement ... puisque personnellement en France "ils" m'en ont attribué quand même NEUF ! Dont un commençant par 2, si si, et même un commençant par 8, extra terrestre je suppose ? Mais personne dans leurs services ne m'a JAMAIS répondu à ce sujet, ni même n'a pris le soin de s'en excuser ? ? ?)
Je cite cet exemple personnel, car là ENCORE cela démontre de façon flagrante la STUPIDITÉ de certains programmes, puisque la LOGIQUE, le MOINDRE BON SENS voudraient que SEULS 1 et 2 soient normalement autorisés dans ce genre de système pour cette case, NON ?
Notez par ailleurs que cet index est parfaitement visible dans XWD puisque chacun de nos objets, que ce soit dans la Médiathèque comme pour nos Pages etc. se voit attribuer un numéro, genre mon_image.1234.jpg par exemple en publication avec pour sous extension 1234 qui est dont le numéro d'Index dans la Base de Données du fichier site !

Il faudra d'ailleurs ensuite travailler en partant de cet Index unique, une fois identifié par un paramètre quelconque, pour renvoyer des données suite à toute requête et NON en partant du paramètre ! (Pour exemple, là ENCORE dans les systèmes débiles, Pôle Emploi il y a quelques temps m'a déménagé sans préavis ni que je le sache à AVIGNON alors que la CAF m'avait déménagé à CARCASSONNE ? Quant aux Impôts, j'avais QUATRE "Compteur", allez donc savoir pourquoi ? Et une pluie de pénalités puisque n'ayant payé qu'une fois, les autres restaient impayés pardi ! ! ! Après certains sont étonnés par la DENT que j'ai envers toutes ces Administrations et la majorité d'incompétents irresponsables qui y "travaillent" ?)

Vous aurez donc là encore compris le soin à apporter pour nourrir et surtout identifier clairement l'ensemble de vos données ? Et ça, ce ne sera PAS issu du programme lui même mais UNIQUEMENT de l'application personnelle de VOS raisonnements... L'informatique NE POURRA JAMAIS tout faire à VOTRE place !


Maintenant, raisonnons un peu quant aux contenus de nos donnés si vous le voulez bien ? Disons que dans la majorité des cas, ce sera du texte, qu'il s'agisse de texte pur comme un Titre, une Description par exemple, ou des chiffres dans le cas d'un tarif ? Peu nous importe d'ailleurs, ce seront les requêtes qui ensuite seront amenées à manier ces données, soit pour les afficher ou remplir des Cases dans un Formulaire par exemple, soit effectuer des calculs divers...
Un cas particulier concerne les Images ! Là encore me direz vous, ce n'est que du texte ? Enfin ... des caractères plutôt, peu ou prou compréhensibles d'ailleurs pour les humains, sauf si le fichier est lu en hexadécimal, auquel cas un habitué pourra plus facilement comprendre la couleur et la position de chaque pixel; néanmoins de là à arriver à visualiser l'Image, autant passer par un programme adéquate, ça ira beaucoup plus vite et surtout sans "se prendre la tête"...
Néanmoins, la longueur du "texte" peut devenir énorme pour ne pas dire gigantesque ? Et si nous avons un minimum d'intelligence pour raisonner en mode informatique, aller se mettre en mémoire la donnée suivante après une image de 4 Mo par exemple... Et encore bien pire si nous avons par exemple pour un Hôtel une dizaine d'Images dans ce genre ? Voire, si nous avons une centaine d'Hôtels, chacun avec leurs dix Images ? ? ?
Dit autrement, nous allons charger la mémoire d'un tas de caractères inutiles pour la plus grande majorité, puisque le plus souvent ce tas d'Images ne sera vu par personne...

Vous comprendrez donc de suite qu'il est profondément DÉBILE d'inclure des Images comme objet dans une Base de données, et que SEULS les IMBECILES NOTOIRES n'ayant encore RIEN COMPRIS à l'essence même de l'Informatique persisteront, continueront à stocker, ENCOMBRER les Bases de Données avec des IMAGES ! ! ! Ils feraient même mieux d'ailleurs de ne PAS s'en vanter, comme lu sur un certain Forum ? Car cela démontre, UNE FOIS DE PLUS s'il fallait encore le prouver, leurs INCOMPÉTENCE et surtout IRRESPONSABILITÉ de pseudo "professionnel" ?

L'intelligence sera donc, exactement comme il est fait sur CE Forum (Cf. Image ci dessous...), de stocker les Images dans un /Répertoire privé, qu'il est d'ailleurs possible de verrouiller en sécurité via un fichier .htaccess adéquate, et dans ce cas renommées par des noms de fichier aléatoires, par exemple azert12tyuio45, ni plus ni moins ? Lequel Code azert12tyuio45 sera contenu LUI dans la Base de données, donc trois fois rien en matière de lecture et de place en mémoire, pour ensuite seulement être chargée uniquement à la demande de visualisation, auquel cas la requête se verra attribuer l'ordre d'aller chercher le fichier azert12tyuio45 à tel endroit, donc via tel chemin d'accès et à l'aide de telle clef d'accès, puis de lui attribuer le nom de mon_image_a_moi.jpg pour l'affichage ?

Dans le même ordre d'idée, il est parfaitement possible, pour de très très volumineux fichier texte ou même au format .pdf de ne PAS les inclure dans nos Bases de données, mais d'en disposer dans un /Répertoire idoine, et de placer dans les Bases UNIQUEMENT un Lien "poids plume" en lieu et place ?

Disons que cela revient à la comparaison déjà faite X fois ici comme ailleurs à propos de Flash, ou soit c'est créé en "tout embarqué", soit Programme, Images et même Sons tous dans le même sac, d'où un fichier volumineux qui ne se lancera qu'une fois tout chargé sur la machine du Visiteur si ça veut bien passer, soit uniquement le programme pur, les ressources étant appelées par un xml voisin, avec un affichage rapide dès que le Programme et seulement la PREMIÈRE Image sont chargées ? Les autres ayant le temps d'arriver puisque placées "ensuite"...


Bref, un PROgrammeur, un VRAI, rajoutera toujours deux lignes de Code dans son programme de gestion de ses Bases de données afin de stocker les fichiers de certains types ou trop volumineux à partir d'un certain seuil, paramétrable pourquoi pas, dans un endroit adéquate, voire même sous Windows carrément avec un attribut caché, sous réserve d'ajouter une sauvegarde sous la forme d'un fichier zippé englobant le total ?

A méditer quant à la construction d'XWebDesignor, qui sur des fichiers trop volumineux finit toujours par planter sur de grosses Pages avec beaucoup de [Composant]s restés activés ? Par exemple...


Cordialement, Yvanoph---

Journalisée

La théorie, c'est quand on sait tout mais qu'absolument rien ne fonctionne !

La pratique, c'est quand tout fonctionne "farpaitement" sans vraiment savoir pourquoi, ni d'ailleurs  chercher à comprendre...

Chance inouïe, ici théorie et pratique fonctionnent  !
Tags: MySQL base de données Gestion: Données 
Pages: [1]   Haut de page
  Imprimer  
 
Aller à:  

Propulsé par MySQL Propulsé par PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines
Soutenir Yvanoph par un Don ?
Boréal - V 1.0 by Yvanoph | Sitemap
XHTML 1.0 Transitionnel valide ! CSS valide !
Page générée en 0.136 secondes avec 21 requêtes.