Quels sont les interets des base de données ?

Quels sont les interets des base de données ? - SQL/NoSQL - Programmation

Marsh Posté le 16-12-2005 à 23:24:58    

Je fais de la programmation et je me suis toujours demandé a quoi peuvent servir les bases de donnée, pour moi ce sont de simple fichier qui contienent des informations, qu'ont ils de si bien et pourquoi y en a-t-il de différente sorte Sql Oledb...

Message cité 1 fois
Reply

Marsh Posté le 16-12-2005 à 23:24:58   

Reply

Marsh Posté le 16-12-2005 à 23:35:32    

pour faire parler les développeurs qui savent pas se taire :o


---------------
Nos estans firs di nosse pitite patreye...
Reply

Marsh Posté le 16-12-2005 à 23:53:44    

Pour que tu te rendes compte des services que peut rendre une base de données, essaies par exemple de faire un simple annuaire (exemple pagesjaunes) géré dans un simple fichier. Remplis le de plusieurs millions d'enregistrements (aléatoirement si tu veux). Ensuite essaies d'en tirer des choses utiles, par exemple tous les noms commençants par "Dup", du départment 26, dont l'activité se rapporte au domaine médical.
 
Ainsi déjà si tu arrives à faire ça en moins d'une journée, avec des performances qui tiennent la route et une fiabilité qui justifie de confier tes données à cet outil tu peux considérer que tu viens de réaliser un exploit. Dans le cas contraire sache que tu peux faire ça en quelques heures (quelques minutes même avec un truc comme ACCESS :) ) avec n'importe quelle base de données. Le SQL, qui est un langage normalisé dédié aux bases de données relationnelles te permet, principalement (mais pas que) d'interroger ta base facilement et assez naturellement (une fois compris le principe). Tu peux ainsi extraire des données filtrées, triées, synthétisées beaucoup plus facilement et rapidement (dans la mesure ou les moteurs de base de données sont hautement optimisés) que si tu devais programmer ça à la main.
 
Tout ceci est dit vite fait afin de te donner une idée de la chose, le sujet est vaste et l'information abondante sur internet.


Message édité par nono973 le 16-12-2005 à 23:55:54
Reply

Marsh Posté le 16-12-2005 à 23:57:29    

Merci

Reply

Marsh Posté le 17-12-2005 à 00:36:17    

Les gros intérêts des bases de données, du moins, les SGBDR, outre le faire qu'il te permettent d'accéder et interroger tes données de façon simples et rapide, ce sont :
- Gestion de la cohérence : mettons que t'as un fichier "produit" et un fichier "commande", ca va te permettre de bloquer l'enregistrement d'une commande qui porte sur un produit qui n'existe pas.
- Gestion des accès multiples : t'as un fichier contenant des millions d'enregistrements, utilisés par une 100aine de personnes en même temps. C'est pas pratique de gérer des interrogations dans ce fichier en // et quasi impossible de gérer en même temps des écritures dans ce fichier.
- Gestion des transactions : ca simple, je vais au distributeur de billets. je demande 500 €. l'appli va vérifier que j'ai bien 500 € sur mon compte, débiter ce dernier des 500 €, mettre à jour mon encours carte bleue, puis enfin me donner les billets. seulement, proutch, à ce moment, y'a plus de billets, ou carrément l'appli plante (coupure de courant ou autre). vu que c'est géré en transaction, une base de données va savoir immédiatement annuler les actions et laisser mon compte tel qu'il était avant l'oppération annulée. Avec une gestion de fichier, notamment le coup de la panne de courant, c'est quasi impossible à gérer.
- Service partagé d'accès aux données : maintenant, c'est bien, t'as un distributeur de billets qui marche, qui résiste à tout, et c'est génial. Comment tu fais avec des fichiers pour qu'au guichet, où c'est une autre application (donc avec sa propre gestion d'accès aux fichiers) pour pouvoir jouer dedans ? Avec une base de données, ça ne pose aucun problème.
 
Y'a tout un tas d'autres intérêts, mais je pense que ceux-là sont les principaux.

Reply

Marsh Posté le 17-12-2005 à 00:37:00    

l'intérêt principal des bdd c'est de stocker des informations, comme tu le dis, un peu comme des fichiers
sauf que ces informations sont ordonnées et agencées selon différents principes et algorithmes, à la fois pour réduire la taille totale de stockage (sans perte d'informations bien entendu), et aussi pour pouvoir plus facilement trouver des informations précises : statistiques, dénombrements, correspondances de champs, recoupements d'informations, etc.
de la même manière, l'accès aux informations est optimisée par la gestion faite par le SGBD, notamment en proposant d'interroger la bdd selon des critères évolués (langage sql)


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
Reply

Marsh Posté le 17-12-2005 à 00:39:38    

vous vous concentrez trop sur la gestion des données les gars, vous êtes trop pollués par mysql ;) :p

Reply

Marsh Posté le 17-12-2005 à 00:47:30    

bah. apparemment, on est loin d'être aussi calé que toi :)
question intéressante en fait


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
Reply

Marsh Posté le 17-12-2005 à 00:51:26    

sinon, un autre intérêt que je vois, mais tout le monde n'est pas du même avis, c'est la possibilité de déporter un certain nombre de traîtements dans le moteur de la base.
 
ainsi, pour des données partagées entre plusieurs application, on peut facilement garantir un traîtement identique des données.
 
exemple que j'ai fait ce soir (totalement inutile, donc c'est un truc bon exemple :D) :
 
euh... attendez, je change de PC :D

Reply

Marsh Posté le 17-12-2005 à 01:13:35    

Alors voilà, je fais un petit jeu du pendu (mais ça pourrait être n'importe quoi d'autre).
 
j'ai une table dans laquelle je mets les mots qu'apprend le serveur, avec un flag qui indique la langue de chaque mot.
Et pour que le jeu puisse suggérer de façon intelligente des lettres, j'ai une table lettre, qui va associer ne nombre d'occurences de chaque lettre pour chaque mot. Ainsi, pour que le jeu aie plus de chances de trouver, il va aller chercher quelles sont les lettres les plus courantes pour la langue du mot recherché.
 
La structure des deux tables :

Code :
  1. CREATE TABLE [dbo].[mot] (
  2. [id] [numeric](18, 0) IDENTITY (1, 1) NOT NULL ,
  3. [mot] [varchar] (50) COLLATE French_CI_AS NOT NULL ,
  4. [language] [char] (2) COLLATE French_CI_AS NOT NULL
  5. ) ON [PRIMARY]
  6. GO
  8. CREATE TABLE [dbo].[lettre] (
  9. [lettre] [char] (1) COLLATE French_CI_AS NOT NULL ,
  10. [mot_id] [numeric](18, 0) NOT NULL ,
  11. [nb] [tinyint] NOT NULL
  12. ) ON [PRIMARY]
  13. GO


 
OK, c'est cool.
Sauf que si je décide que depuis l'application web je puisse entrer des mots, mais aussi via un petit intégrateur afin d'ajouter un dictionnaire entier d'un coup, ça va me lourder de dupliquer le code de splitage des mots en lettres.
 
J'ai donc fait les triggers suivants :

Code :
  1. CREATE TRIGGER upperMot ON dbo.mot
  2. instead of INSERT
  3. AS
  4. insert into mot (mot, language) (select upper(mot), upper(language) from inserted)


Ce trigger est lancé avant que l'insertion d'un mot soit effective (plus exactement "à la place de l'insert", car SQL Server ne reconnait pas "before insert" mais ça revient au même ici. Il ne sert pas à grand chose, juste à ne stocker dans la base que des mot en majuscules (à la place de l'instruction initiale, je fais la même en mettant le mot en majuscules).
 
Ensuite, un second trigger, sur la même table, va se lancer une fois l'insertion du mot terminée "after insert" :

Code :
  1. CREATE TRIGGER addMot ON dbo.mot
  2. AFTER INSERT
  3. AS
  4. declare @umot as varchar(50)
  5. declare @i as tinyint
  6. select @umot = mot from inserted
  7. set @i = 0
  9. while (@i < len(@umot))
  10. begin
  11.       select @i = @i + 1
  12.       insert into lettre (lettre, mot_id, nb)
  13.       values (substring(@umot, @i, 1), ident_current('mot'), 1)
  14. end


Là, pour chaque lettre, on l'extrait, et on l'insert simplement dans a table des lettres, tout en laisse le système insérer le mot tel quel dans la table mot.
 
Mais c'est pas tout.
Si je mets le mot "toto", ça sert à rien de faire deux lignes avec "T" et deux lignes avec "O". Donc malgré la commande "insert" dans la table "lettre", je veux que la ligne existe déjà, je fasse un update dessus en incrémentant le nombre d'occurences (champ NB de la table lettres).
Et si y'avait que ça... Maintenant, je peux avoir le mot "édition". Seulement, la lettre É et la lettre E ne sont pas les mêmes en SQL. Moi ça m'embête, dans un jeu du pendu on ne fait pas la différence.
Du coup, je vais devoir, lettre par lettre, virer les accents.
Idem pour le cas des lettres æ et œ : ben en fait, c'est deux lettres ! (AE et OE)
Donc, voici le trigger exécuté à la place de l'insertion dans la table "lettre" :  

Code :
  1. CREATE TRIGGER addLettre ON [dbo].[lettre]
  2. INSTEAD OF INSERT
  3. AS
  4. declare @lettre1 as char(1)
  5. declare @lettre2 as char(1)
  6. declare @mot_id as numeric
  7. declare @nb as tinyint
  9. select @lettre1 = lettre, @mot_id = mot_id, @nb = nb from inserted
  11. -- Je ne peux pas utiliser de "IN" parcequ'en SQL, c'est très con, si É ou Æ ne sont pas égaux à des lettres de A à Z, ils sont pourtant dans l'interval A..Z
  12. if @lettre1 in ('A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z')
  13. begin
  14.    set @lettre2 = ' '
  15. end
  16. -- Cas des A accentués
  17. else if @lettre1 in ('À', 'Á', 'Â', 'Ã', 'Ä', 'Å')
  18. begin
  19.    set @lettre1 = 'A'
  20.    set @lettre2 = ' '
  21. end
  22. -- Cas du C cédille
  23. else if @lettre1 = 'Ç'
  24. begin
  25.    set @lettre1 = 'C'
  26.    set @lettre2 = ' '
  27. end
  28. -- Cas du E accentué
  29. else if @lettre1 in ('È', 'É', 'Ê', 'Ë')
  30. begin
  31.    set @lettre1 = 'E'
  32.    set @lettre2 = ' '
  33. end
  34. -- Cas du I accentué
  35. else if @lettre1 in ('Ì', 'Í', 'Î', 'Ï')
  36. begin
  37.    set @lettre1 = 'I'
  38.    set @lettre2 = ' '
  39. end
  40. -- Cas du N accentué
  41. else if @lettre1 = 'Ñ'
  42. begin
  43.    set @lettre1 = 'N'
  44.    set @lettre2 = ' '
  45. end
  46. -- Cas du O accentué
  47. else if @lettre1 in ('Ò', 'Ó', 'Ô', 'Õ', 'Ö')
  48. begin
  49.    set @lettre1 = 'O'
  50.    set @lettre2 = ' '
  51. end
  52. -- Cas du U accentué
  53. else if @lettre1 in ('Ù', 'Ú', 'Û', 'Ü')
  54. begin
  55.    set @lettre1 = 'U'
  56.    set @lettre2 = ' '
  57. end
  58. -- Cas du Y accentué
  59. else if @lettre1 = 'Ý'
  60. begin
  61.    set @lettre1 = 'Y'
  62.    set @lettre2 = ' '
  63. end
  64. -- Cas des lettres "double"
  65. else if @lettre1 = 'Æ'
  66. begin
  67.    set @lettre1 = 'A'
  68.    set @lettre2 = 'E'
  69. end
  70. else if @lettre1 = 'Œ'
  71. begin
  72.    set @lettre1 = 'O'
  73.    set @lettre2 = 'E'
  74. end
  75. else
  76. -- Cas des autres caractères tels que '-' par exemple
  77. begin
  78.    set @lettre1 = ' '
  79.    set @lettre2 = ' '
  80. end
  82. -- On a bien trouvé une lettre
  83. if @lettre1 != ' '
  84. begin
  85.    if exists(select null from lettre where lettre = @lettre1 and mot_id = @mot_id)
  86.    begin
  87.       -- La lettre a déjà été inscrite pour ce mot : on incrémente le compteur
  88.       update lettre set nb = nb + @nb where lettre = @lettre1 and mot_id = @mot_id
  89.    end
  90.    else
  91.    begin
  92.       -- C'est la première occurence de la lettre pour ce mot
  93.       insert into lettre (lettre, mot_id, nb) values (@lettre1, @mot_id, @nb)
  94.    end
  95. end
  97. -- On a trouvé une seconde lettre (cas des lettres "doubles" )
  98. if @lettre2 != ' '
  99. begin
  100.    if exists(select null from lettre where lettre = @lettre2 and mot_id = @mot_id)
  101.    begin
  102.       -- La lettre a déjà été inscrite pour ce mot : on incrémente le compteur
  103.       update lettre set nb = nb + @nb where lettre = @lettre2 and mot_id = @mot_id
  104.    end
  105.    else
  106.    begin
  107.       -- C'est la première occurence de la lettre pour ce mot
  108.       insert into lettre (lettre, mot_id, nb) values (@lettre2, @mot_id, @nb)
  109.    end
  110. end


Et voilà !
 
Maintenant, si je veux ajouter un mot, je n'ai qu'à l'ajouter dans la table des mots (avec un bête "insert" ), et zou, ça va me le découper en rondelles comme je veux. ça fait autant de code en moins à faire dans chacune des applications succeptibles d'ajouter des mots à ma base.
Mieu ! J'ai mis une contrainte d'unicité sur "mot,langage". Si je tente d'insérer un doublon, bête et discipliné, la base va commencer à faire le travail, et une fois terminé, elle va s'appercevoir qu'elle ne peut pas. Pas de panique : les triggers sont transactionnels : toutes les lettres qui ont commencée à s'écrire dans la base vont être supprimée aussitôt, en même temps qu'une erreur d'unicité sera levée !
 
Mais c'est pas tout ! Il ne faut pas que je puisse modifier un mot déjà existant : en effet, ce serait trop le bordel de recompter les lettres par trigger, je suis fénéant. Du coup, en gérant les droits sur la table, je ne permets que l'ajout et la suppression d'un mot. Jamais sa modification.
Pareil pour les lettres : je ne dois ni pouvoir les mettre à jour, ni les supprimer, ni même les ajouter à la main : je vire tous les droits sur cette table.
 
Et enfin, grace à l'option "cascade on delete" sur la FK entre "mot.id" et "lettre.mot_id", si je supprime un mot, je vais aussitôt effacer les lettres associées. Et malgré une interdiction de supprimer dans la table lettres, l'intérité des données étant la plus forte, ça va supprimer quand même par propagation dans la table lettres, alors que je n'ai pas le droit de le faire à la main !
 
Et pour finir, parceque tout le monde n'a pas à connaître la structure de ma base, j'interdit les select sur "lettres" et "mot", et j'ai fait une vue qui permet de récupérer les lettres les plus souvent utilisées dans les mots pour chaque langage :

Code :
  1. CREATE VIEW lettre_count
  2. AS
  3. SELECT     dbo.mot.[language], dbo.lettre.lettre, SUM(dbo.lettre.nb) AS nb_total
  4. FROM         dbo.lettre INNER JOIN
  5.                       dbo.mot ON dbo.lettre.mot_id = dbo.mot.id
  6. GROUP BY dbo.mot.[language], dbo.lettre.lettre


Message édité par Arjuna le 17-12-2005 à 15:20:54
Reply

Marsh Posté le 17-12-2005 à 01:13:35   

Reply

Marsh Posté le 17-12-2005 à 01:31:27    

oulla, je relirai tout ça demain. j'ai été largué au bout de 5 lignes. qui a tenu plus lgtmps que moi ? :D

Message cité 1 fois

---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
Reply

Marsh Posté le 17-12-2005 à 04:06:21    

eviljojo22 a écrit :

Je fais de la programmation et je me suis toujours demandé a quoi peuvent servir les bases de donnée, pour moi ce sont de simple fichier qui contienent des informations, qu'ont ils de si bien et pourquoi y en a-t-il de différente sorte Sql Oledb...


 
C'est une conspiration contre les étudiants enfait c'est pour les défoncer au partiels  :heink:


---------------
Scheme is a programmable programming language ! I heard it through the grapevine !
Reply

Marsh Posté le 17-12-2005 à 11:49:15    

trevor a écrit :

oulla, je relirai tout ça demain. j'ai été largué au bout de 5 lignes. qui a tenu plus lgtmps que moi ? :D


chais bien que je fais des tas de fautes mais quand même :o :p

Message cité 1 fois
Reply

Marsh Posté le 17-12-2005 à 12:45:11    

Arjuna a écrit :

chais bien que je fais des tas de fautes mais quand même :o :p


 
ah nonon pas du tout. c'est pas lié aux fautes (j'en ai pas vu d'ailleurs), c'est que ça a l'air assez pointu ce que tu as décris, et que je m'y connais pas à fond dans le domaine. mais je pense que la lecture (et la compréhension) de tes explications me permettraient d'en savoir un peu plus, et c'est tjs intéressant :)


---------------
TReVoR - http://dev.arqendra.net - http://info.arqendra.net
Reply

Marsh Posté le 17-12-2005 à 15:05:40    

si t'as pas vu de fautes, c'est peut-être pour ça que t'as rien compris alors, parceque par moment c'est incompréhensible si on lit tel quel :D
 
bon, je corrige ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed