Optimisation stockage de données

Bonjour à tous,

Utilisateur de MySQL depuis des années et MariaDB depuis peu, pour la première fois, je me pose la question de la place que prend une base de données sur mon disque dur... Et là, c'est le choc !

Je crée une base toute simple, une table à 2 colonnes : id (auto increment) et data (varchar 256, mais j'ai essayé char 4, varbinary, et autres...)

Lorsque je remplis 5000 lignes en écrivant dans data soit un string de 8 caractères en hexadecimal (ex: 5b435431), soit un string de 4 caractères (ex: [CT1) correspondant au pack(H*, $string_hexadecimal) , la taille de la table reste invariable, soit 149.7 ko ...

Le problème c'est que 149700 / 5000 , ça fait ~30 ... 30 octets pour stocker seulement 4 caractères d'un octet (en théorie) ou 8 caractères sur 4 bits (hexadecimal)... c'est trop ! Evidemment, il faut des séparateurs, et je ne sais pas si les id auto incrémentés sont vraiment stockés, mais même si c'est le cas, on arrive vraiment à 30 octets... ?

J'ai donc fait des tests en changeant les interclassements pour la base (ascii divers, binary, latin1 divers, utf divers...), mais rien n'y fait, je n'ai pas obtenu mieux...

J'ai ensuite refait les mêmes tests en écrivant 5000 lignes, avec dans data des string de 32 caractères (ex: [CT1[CT1[CT1[CT1[CT1[CT1[CT1[CT1) correspondant au pack(H*, $string_hexadecimal) , et dans ce cas là, la taille de la table n'est pas proportionnelle et change de plus en plus selon l'interclassement : utf8mb4_general_ci : 355 ko , latin1_swedish_ci : 266 ko , binary : 266 ko

Il y a visiblement des pertes avec l'utf8mb4 mais je ne sais pas pourquoi (ce n'est pas sur 8 bits ?!) , et avec binary ou swedish, 266 ko, ça fait 53 octets par ligne (pour 32 caractères sur 8 bits chacun, soit 19 octets de "perdus")... J'imagine que cela devient négligeable dès lors qu'on stocke plus d'une centaine d'octets par ligne.

Quelqu'un aurait il malgré tout une idée pour faire plus économique en place ou c'est le mieux qu'on puisse faire ?

Merci à tous.

Salut User41.

Code:

---

1 2 3 4 5

CREATE TABLE `Trav` ( ... ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_cs` ROW_FORMAT=COMPRESSED;

---

Le jeu de caractères "latin1" codifie 1 caractère sur 1 octet.
Le format "compressed" permet de gagner un peu de place.

Cordialement.
Artemus24.
@+

Effectivement MySQL gère très mal le stockage du fait de l'UTF8 qui est une vaste merde hélas plébiscité par les développeurs qui n'ont aucune vision du problème.

L'UTF8 suppose de coder :

• les caractères latin non diacritiques (pas d'accent, cédille, ligature...) sur 1 septet, réservant le 8e bit pour indiquer que dans la chaine, ce caractères est codé sur 1 seul octet.
• Puis les caractères diacritiques latin sur un "quinzet" c'est à dire sur 15 bits, réservant le 16e bit pour indique que le caractère est codé sur 2 octets.
• Puis les caractères des langues non indo européennes (hebreu, arabe, chinois, thaï...) sur 23 bits, réservant le 24e bit pour indiquer que le caractère est codé sur 3 octets.

Ceci est censé compresser les chaines de caractères envoyées sur internet, pour "aller plus vite".

Sauf que cela pose de multiples inconvénients :
1) la langue anglaise est favorisé car dénuée d'accents, au détriment de toutes les autres langues latines...
2) la comparaison de chaines de caractères en fonctions de spécificité de collation (confusion des accents notamment) devient très complexe)
3) le calcul de la longueur d'une chaine en nombre de caractères devient problématique...
4) le tri sémantique des données est cauchemardesque et très lent
etc.

Ceci pose bien évidemment le problème de l'hégémonie des USA sur l'informatique au détriment de tous les autres pays n'ayant pas la langue anglaise comme moyen de communication... Mais passons
Il est a remarquer que Microsoft avait proposé d'utiliser l'UTF16 bien plus "smart" pour les pays d’Europe, d’Afrique et d'Amérique du sud, et à refusé d'intégrer l'UTF8 pendant longtemps... Mais hélas la bêtise l'a emportée...

MySQmerde a préféré jouer à fond la carte de l'américanisme en prônant à outrance le type UTF8... Sauf que pour que cela fonctionne dans une BD ou les comparaisons (jointures, clause de filtrage WHERE et HAVING, tris avec ORDER BY, groupage avec GROUP BY, dédoublonnement avec DISTINCT...) sont légions, il n'est pas possible de travailler directement avec l'encodage UTF8 tel que le standard l'impose...
Alors, MySQmerde a bricolé un système dans lequel tout caractère stocké en soit-disant UTF8 est en fait stocké sur 3 octets !!!!

Et voila la raison pour laquelle vous perdez tant de place pour vos maigres caractères, qu'un autre SGBD, SQL Server pour ne pas le nommer, stocke systématiquement sur un seul octet en CHAR ou VARCHAR...

De plus les index MySQmerde étant limité à 767 octets, cela fait qu'en UTF8 vous ne pourrez avoir que 255 caractères dans un index... Là ou SQL Server permet d'avoir jusqu'à 1600 caractères...

Bienvenu dans le monde de merde de MYSQL !
A lire en complément : https://blog.developpez.com/sqlpro/p...oudre_aux_yeux

A +

Citation:

---

Envoyé par Artemus24

Le format "compressed" permet de gagner un peu de place.

---

Oui, mais c'est au détriment des performances !

A +

Salut SQLPRO.

Citation:

---

Envoyé par SQLPRO

L'UTF8 suppose de coder :
les caractères latin non diacritiques (pas d'accent, cédille, ligature...) sur 1 septet, réservant le 8e bit pour indiquer que dans la chaine, ce caractères est codé sur 1 seul octet.

---

Ce jeu de caractères correspond à la table ASCII, codé sur sept bits.
C'est commun à toutes les codifications des jeux de caractères existantes.

Cordialement.
Artemus24.
@+

Citation:

---

Envoyé par Artemus24

Salut SQLPRO.

Ce jeu de caractères correspond à la table ASCII, codé sur sept bits.
C'est commun à toutes les codifications des jeux de caractères existantes.

---

Absolument pas !!!!

Cela ne concerne que les caractères encodées en ASCII et en UNICODE pour les 128 premiers.

Mais il existe de nombreux autres encodages....

Par exemple la famille EBCDIC inventée par IBM et déclinée en 10 déclinaisons...
https://fr.wikipedia.org/wiki/Extend...terchange_Code

C'est encore très largement utilisé dans le monde IBM des grands systèmes, mais aussi de l'AS 400 que de nombreuses PME utilisent encore de nos jours.

Microsoft SQL Server permet d'utiliser le jeu EBCDIC et les collations sui vont avec :

Code:

---

1 2 3 4 5 6 7 8 9 10

SQL_EBCDIC037_CP1_CS_AS Latin1-General, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 210 on Code Page 1252 for non-Unicode Data SQL_EBCDIC1141_CP1_CS_AS German-PhoneBook, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 219 on Code Page 1252 for non-Unicode Data SQL_EBCDIC273_CP1_CS_AS German-PhoneBook, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 211 on Code Page 1252 for non-Unicode Data SQL_EBCDIC277_2_CP1_CS_AS Danish-Norwegian, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 218 on Code Page 1252 for non-Unicode Data SQL_EBCDIC277_CP1_CS_AS Danish-Norwegian, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 212 on Code Page 1252 for non-Unicode Data SQL_EBCDIC278_CP1_CS_AS Finnish-Swedish, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 213 on Code Page 1252 for non-Unicode Data SQL_EBCDIC280_CP1_CS_AS Latin1-General, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 214 on Code Page 1252 for non-Unicode Data SQL_EBCDIC284_CP1_CS_AS Modern-Spanish, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 215 on Code Page 1252 for non-Unicode Data SQL_EBCDIC285_CP1_CS_AS Latin1-General, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 216 on Code Page 1252 for non-Unicode Data SQL_EBCDIC297_CP1_CS_AS French, case-sensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 217 on Code Page 1252 for non-Unicode Data

---

A +

Citation:

---

Envoyé par Artemus24

Salut User41.

Code:

---

1 2 3 4 5

CREATE TABLE `Trav` ( ... ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_cs` ROW_FORMAT=COMPRESSED;

---

Le jeu de caractères "latin1" codifie 1 caractère sur 1 octet.
Le format "compressed" permet de gagner un peu de place.

Cordialement.
Artemus24.
@+

---

Bonjour Artemus, merci pour l'astuce, je ne connaissais pas "compressed" ! Cela dit, dans le cas présent, ce sera difficile à compresser...

Il me semblait que latin1 était sur 7 bits plus 1 bit servant à autre chose... (ou alors je confonds avec ascii) je n'avais pas bien saisi, mais tant mieux.

J'ai testé InnoDB mais c'était incroyablement plus lent que MyIsam pour insérer... donc revenu à MyIsam

Merci à SQLpro pour ces explications ! J'ai essayé de m'intéresser à cette problématique mais effectivement, elle semble sans limites :D

Mon problème va être le suivant : créer plus d'un milliard de lignes sur plus d'un téra octets... Pensez vous qu'il soit plus judicieux de diviser ma table en plusieurs tables ou de tout faire passer en une seule ? Savez vous notamment si ma colonne id (auto increment) stocke effectivement des numéros pour chaque ligne ? (l'id "546 052 377" par exemple prenant déjà une certaine place) Quelle place réelle prendrait cette seule colonne et y'a t il moyen de rogner quelque chose là dessus ?

Merci encore.

Le type integer est le plus économe en espace occupé.
Le plus large, le bigint, n'occupe que 8 octets pour 2⁶⁴ valeurs possibles (2⁶³ si signé) !
L'integer "normal" occupe 4 octets pour plus de 4 milliards de valeurs possibles en non signé.
Ce n'est donc pas la colonne de l'identifiant qui encombre l'espace disque ni le réseau (sauf si on a choisi un autre type que de l'integer, ce qui est le plus souvent une erreur).
Donc l'id "546 052 377" n'occupe pas "une certaine place", mais seulement les 4 octets du type integer ou les 8 du type bigint, rien de plus ;)

Il n'y a aucun intérêt à multiplier les tables à cause du volume, par contre, il y a intérêt à les partitionner.

Salut à tous.

Citation:

---

Envoyé par user41

Il me semblait que latin1 était sur 7 bits plus 1 bit servant à autre chose... (ou alors je confonds avec ascii) je n'avais pas bien saisi, mais tant mieux.

---

Latin1 est codé sur huit bits et donc 1 caractère est stocké dans 1 octet.
Les 128 premiers caractères sont ceux de l'ASCII.
Les autres 128 caractères sont ceux de la norme de l'Europe occidentale.
Une extension de ce ISO-8859-1 est l'ISO-8859-15 avec en particulier le symbole monétaire de l'euro (€).

Si tu travailles uniquement en français et en anglais, le mieux est d'utiliser ISO-8859-1 ou ISO-8859-15.
Le problème avec l'UTF-8 est la variabilité de la taille du caractère stockée.
Si tu prends par exemple UTF8MB4 cela va de 1 octet à 4 octets.
Il est pourtant conseillé de choisir ce jeu de caractères (charset) mais cela pose quelques problèmes au stockage.

Citation:

---

Envoyé par user41

J'ai testé InnoDB mais c'était incroyablement plus lent que MyIsam pour insérer... donc revenu à MyIsam

---

C'est normal car il y a une gestion des transactions qui ne se fait pas dans MyIsam.
Si tu as presque jamais des mises à jour mais beaucoup de lectures, MyIsam est l'idéal.
Inversement, si tu as beaucoup d'insertions et de mises à jour, le mieux est InnoDB.
Il y a une gestion de l'intégrité des données qui ne se fait pas dans MyIsam.
Ce sont les "commit" et "rollback" que l'on fait entre deux points de sauvegardes.
Il y a aussi la gestion des clefs étrangères, ...

Citation:

---

Envoyé par user41

Mon problème va être le suivant : créer plus d'un milliard de lignes sur plus d'un téra octets...

---

Avant de faire quoi que ce soit, il faut commencer par modéliser votre base de données.
Il s'agit de définir les relations entre les différentes entités qui va constituer votre modèle d'information.
Les aspects techniques viennent plus tard.

Citation:

---

Envoyé par user41

Pensez vous qu'il soit plus judicieux de diviser ma table en plusieurs tables ou de tout faire passer en une seule ?

---

En admettant que tout rentre dans un disque, pour répondre à votre question, cela dépend de ce que vous faites sur vos tables.
Admettons qu'une partie de vos données concerne de l'archivage.
Le mieux est alors de créer des tables partitionnées, c'est-à-dire un stockage ayant comme critère le mois ou l'année.
Je pense à la gestion des chèques que l'on photocopie recto et verso.
Les relevés des comptes bancaires doivent être conservé au moins cinq ans.
Cela fait un paquet de chèques à stocker sachant qu'il y en a plusieurs milions par jour.

Citation:

---

Envoyé par user41

Savez vous notamment si ma colonne id (auto increment) stocke effectivement des numéros pour chaque ligne ?

---

Ce sont bien des nuuméros, mais dans la représentation binaire.
La taille de cette colonne "ID" dépend du type que vous utilisez. Par exemple :
--> tinyint : 1 octet
--> smallint : 2 octets
--> medium : 3 octets
--> integer : 4 octets
--> bigint : 8 octets

Citation:

---

Envoyé par Escartefigue

Le type integer est le plus économe en espace occupé.

---

Je reconnais que c'est le plus usuel mais cela dépend de ce que l'on y met dedans.
Si la table concerne des références limités en nombres, ne dépasant pas les 255 lignes, le mieux est d'utiliser tinyint.

Citation:

---

Envoyé par user41

Quelle place réelle prendrait cette seule colonne et y'a t il moyen de rogner quelque chose là dessus ?

---

Chaque type peut s'écrire de deux façons différentes, signée ou non signée.
Comme la colonne est auto incrémentée, le mieux est de définir la colonne non signée.
Ainsi le comptage commence à 1 et se termine au maximum de la capacité de stockage du type utilisé.

--> tinyint : -128 à +127 / 0 à 255 (non signé)
--> smallint : -32 768 to + 32 767 / 0 to 65 535 (non signé)
--> mediumint : -8,388,608 à 8,388,607 / 0 à 16,777,215 (non signé)
--> int / integer : -2 147 483 648 à +2,147,483,647 / 0 à 4,294,967,295 (non signé)
--> bigint : -9 223 372 036 854 775 808 à 9 223 372 036 854 775 807 / 0 à 18 446 744 073 709 551 615 (non signé)

Pour ce qui est de l'espace de stockage, il est de plus en plus recommandé de chiffrer ses données.
Si un hacker avait accès au disque où se trouve votre base de données, le mieux est qu'il ne puisse pas les lire.

Il faut savoir qu'une ligne dans une table contient d'autres informations que les colonnes.
De ce fait, une ligne occupe un peu plus que la taille cumulée de chaque colonne.

Cordialement.
Artemus24.
@+

Citation:

---

Envoyé par Artemus24

Latin1 est codé sur huit bits et donc 1 caractère est stocké dans 1 octet.
Les 128 premiers caractères sont ceux de l'ASCII. (...)
Si tu travailles uniquement en français et en anglais, le mieux est d'utiliser ISO-8859-1 ou ISO-8859-15.

---

Vu, en tout cas peu importe dans mon cas tant que cela reste sur un 1 octet fixe.

Citation:

---

Envoyé par Artemus24

C'est normal car il y a une gestion des transactions qui ne se fait pas dans MyIsam.
Si tu as presque jamais des mises à jour mais beaucoup de lectures, MyIsam est l'idéal.
Inversement, si tu as beaucoup d'insertions et de mises à jour, le mieux est InnoDB.
Il y a une gestion de l'intégrité des données qui ne se fait pas dans MyIsam.
Ce sont les "commit" et "rollback" que l'on fait entre deux points de sauvegardes.
Il y a aussi la gestion des clefs étrangères, ...

---

Il n'y aura qu'une seule clé primaire (id). Les mises à jour risquent d'être "par paquets" (de quelques unes à quelques centaines de milliers au max, ce qui va être déjà long)... Est ce à dire que InnoDB est lent en échange de plus de sécurité ? Je n'ai jamais eu de donnée corrompue (je touche du bois). Malgré tout, si une mise à jour de 100 000 lignes doit prendre plus de cinq minutes, ça sera problématique...

Citation:

---

Envoyé par Artemus24

Avant de faire quoi que ce soit, il faut commencer par modéliser votre base de données.
Il s'agit de définir les relations entre les différentes entités qui va constituer votre modèle d'information.
Les aspects techniques viennent plus tard.

---

La base de données sera très simple, pas de relations...

Citation:

---

Envoyé par Artemus24

En admettant que tout rentre dans un disque, pour répondre à votre question, cela dépend de ce que vous faites sur vos tables.
Admettons qu'une partie de vos données concerne de l'archivage.
Le mieux est alors de créer des tables partitionnées, c'est-à-dire un stockage ayant comme critère le mois ou l'année.
Je pense à la gestion des chèques que l'on photocopie recto et verso.
Les relevés des comptes bancaires doivent être conservé au moins cinq ans.
Cela fait un paquet de chèques à stocker sachant qu'il y en a plusieurs milions par jour.

---

Effectivement, une grande partie des lignes ne sera sans doute quasiment jamais mise à jour... Le partitionnage (que je ne connaissais pas) est intéressant et riche d'options, mais je ne suis pas sûr qu'il serait très utile ici dès lors que je n'aurai qu'à lire et modifier les lignes que selon la clé d'index. Mais peut être me trompe je ?

Citation:

---

Envoyé par Artemus24

Je reconnais que c'est le plus usuel mais cela dépend de ce que l'on y met dedans.
Si la table concerne des références limités en nombres, ne dépasant pas les 255 lignes, le mieux est d'utiliser tinyint.

---

Le Int sera très bien dans mon cas, 4 milliards c'est suffisant.

Citation:

---

Envoyé par Artemus24

Pour ce qui est de l'espace de stockage, il est de plus en plus recommandé de chiffrer ses données.
Si un hacker avait accès au disque où se trouve votre base de données, le mieux est qu'il ne puisse pas les lire.

---

Qu'entend-t-on exactement par chiffrer ses données dans MySql dans le cas présent ? Chiffrer par le serveur lui même est il vraiment utile ? Ou bien par le client ? Cela dit, dans mon cas, ce ne sera pas utile.

Citation:

---

Envoyé par Artemus24

Il faut savoir qu'une ligne dans une table contient d'autres informations que les colonnes.
De ce fait, une ligne occupe un peu plus que la taille cumulée de chaque colonne.

---

Y compris dans le cas où il n'y a qu'une unique clé index (auto increment) et quelques autres colonnes ? Hormis les séparateurs ?


Merci en tout cas, c'est instructif !

Salut laurentSc.

Citation:

---

Envoyé par User41

Est ce à dire que InnoDB est lent en échange de plus de sécurité ?

---

Si vous avez des insertions et fréquemment des mises à jour, InnoDB est fait pour eviter des problèmes d'intégrités.

La première des questions que vous devez vous poser est le choix de votre SGBDR.
Oui, MySql est gratuit mais n'est pas nécessairement le mieux adapté à vos problématiques.
Coté fiabilité, Microsoft SQL Server est bien meilleur que MySql.

Ensuite, procédez à la modélisation de votre base de données.
Puis créer vos tables, trigger, procédure stockée ... dans le SGBDR de votre choix.
Puis pour finir, optimiser les performances des accès à vos tables par des requêtes.
Cela ne se fait pas en cinq minutes et nécessites des compétences.

Citation:

---

Envoyé par User41

Je n'ai jamais eu de donnée corrompue (je touche du bois).

---

Quelle est l'origine de vos données ? Un fichier Excel ? Autre ?

Citation:

---

Envoyé par User41

Malgré tout, si une mise à jour de 100 000 lignes doit prendre plus de cinq minutes, ça sera problématique...

---

Comme je ne connais pas votre problématique, il m'est difficile de vous répondre.

Citation:

---

Envoyé par User41

La base de données sera très simple, pas de relations...

---

A priori, vous voulez charger des fichiers séquentiels dans des tables.
Ce n'est pas une bonne idée à cause des répétitions que vous aurez.
Une relation est faite pour éviter toute redondance dans votre base.
Si vous n'utilisez pas les relations, un SGBDR ne vous sert à rien.

Citation:

---

Envoyé par User41

Mais peut être me trompe je ?

---

Vu la volumétrie que vous nous avez signalé, il faut envisager une gestion de l'archivage.
Le partitionnement répond à cette problématique. Que faites vous des lignes les plus anciennes ?

Citation:

---

Envoyé par User41

Le Int sera très bien dans mon cas, 4 milliards c'est suffisant.

---

Dans la clef primaire qui est auto incrémenté, il peut y avoir des trous et c'est tout à fait normal.
Mais si vous devez gérer du tera octets, donc plusieurs milliards de lignes, le mieux est d'utiliser le type "bigint".

Citation:

---

Envoyé par User41

Qu'entend-t-on exactement par chiffrer ses données dans MySql dans le cas présent ?

---

Problème de vocabulaire.

Chiffrer signifie coder et avoir aussi la possibilité de décoder vos données.
Crypter signifie uniquement coder. Pour comparer un mot de passe qui a été crypter et stocké, il faut aussi crypter ce que vous saisissez.

Cela se fait au niveau physique de la base de données.
Mais vous pouvez aussi le faire lors de l'insertion dans vos tables en passant par des fonctions.

Citation:

---

Envoyé par User41

Chiffrer par le serveur lui même est il vraiment utile .

---

Avez vous des informations qui ne doivent pas être lus par tout le monde ?
Il s'agit d'une question de sécurité, pas uniquement les autorisations d'accès à vos données.
Imaginez un hacker qui lit vos données. Est-ce envisageable pour vous ?

Citation:

---

Envoyé par User41

Y compris dans le cas où il n'y a qu'une unique clé index (auto incrément) et quelques autres colonnes ?

---

Oui car l'organisation de vos données sera géré par votre SGBDR.

Cordialement.
Artemus24.
@+

Bonjour à nouveau, et merci d'avoir pris le temps de répondre...

Citation:

---

Envoyé par Artemus24

La première des questions que vous devez vous poser est le choix de votre SGBDR.
Oui, MySql est gratuit mais n'est pas nécessairement le mieux adapté à vos problématiques.
Coté fiabilité, Microsoft SQL Server est bien meilleur que MySql.

---

J'y pense encore, mais je pense rester sur MySql... l'intégrité n'est pas essentielle.

Citation:

---

Envoyé par Artemus24

Quelle est l'origine de vos données ? Un fichier Excel ? Autre ?

---

Des morceaux de fichiers txt envoyés par internet.

Citation:

---

Envoyé par Artemus24

Comme je ne connais pas votre problématique, il m'est difficile de vous répondre.

---

Par exemple, un utilisateur pourrait uploader (au plus gros) un fichier de 20 Mo, découpé par le serveur en 100 000 lignes de 200 octets, chaque ligne étant alors stockée (mise à jour) dans une ligne de la table.

Citation:

---

Envoyé par Artemus24

A priori, vous voulez charger des fichiers séquentiels dans des tables.
Ce n'est pas une bonne idée à cause des répétitions que vous aurez.
Une relation est faite pour éviter toute redondance dans votre base.
Si vous n'utilisez pas les relations, un SGBDR ne vous sert à rien.

---

Pas des fichiers, de simples données (non compressibles et sans répétitions)

Alors en effet, je me suis également posé la question de faire autrement, mais il me semble que traiter directement des fichiers sur le serveur n'était pas forcément plus rapide et économique en place que MySql. (à confirmer ?)

Citation:

---

Envoyé par Artemus24

Vu la volumétrie que vous nous avez signalé, il faut envisager une gestion de l'archivage.
Le partitionnement répond à cette problématique. Que faites vous des lignes les plus anciennes ?

---

Les lignes plus anciennes doivent être conservées, elles restent susceptibles d'être lues de temps à autres (même si jamais mise à jour).

Citation:

---

Envoyé par Artemus24

Dans la clef primaire qui est auto incrémenté, il peut y avoir des trous et c'est tout à fait normal.
Mais si vous devez gérer du tera octets, donc plusieurs milliards de lignes, le mieux est d'utiliser le type "bigint".

---

Des trous ? C'est à dire ?

Je ne dépasserai pas 4 milliards de lignes donc le Int devrait suffire ?! (quelle que soit la taille des lignes)

Citation:

---

Envoyé par Artemus24

Chiffrer signifie coder et avoir aussi la possibilité de décoder vos données.
Crypter signifie uniquement coder. Pour comparer un mot de passe qui a été crypter et stocké, il faut aussi crypter ce que vous saisissez.

---

Pour ma part, je n'aurai besoin ni de l'un ni de l'autre.

Citation:

---

Envoyé par Artemus24

Avez vous des informations qui ne doivent pas être lus par tout le monde ?
Il s'agit d'une question de sécurité, pas uniquement les autorisations d'accès à vos données.
Imaginez un hacker qui lit vos données. Est-ce envisageable pour vous ?

---

Tout à fait, aucun problème pour cela.

Merci encore.

Pour information, si vous devez stocker des LOBs (large OBjects) et notamment des fichiers, la norme SQL 1999 a prévu le DATALINK qui consiste à stocker ces fichiers sous le contrôle du SGBDR. Bien évidement cette fonctionnalité n'existe pas dans MySQL, mais elle est disponible dans SQL Server sous le nom de FILESTREAM. Ceci évite de surcharger inutilement les tables avec des données non relationnelles. De nombreux outil de GED professionnels niveau entreprise utilise cette fonctionnalité pour éviter de stocker directement dans la table. Sharepoint qui est un outil de partage de la connaissance d'entreprise utilise massivement le FILESTREAM. La version gratuite de SQL Server (EXPRESS) permet l'utilisation du FILESTREAM et surtout il n'y a aucune limitation de taille sur les fichiers stockés...

A +

Citation:

---

Envoyé par user41

l'intégrité n'est pas essentielle.
[. . .]
Par exemple, un utilisateur pourrait uploader (au plus gros) un fichier de 20 Mo, découpé par le serveur en 100 000 lignes de 200 octets, chaque ligne étant alors stockée (mise à jour) dans une ligne de la table.

---

Il faut donc :

• un identifiant commun à chacune des 100 000 lignes pour savoir qu'elles constituent un tout cohérent ;
• un chrono propre à chaque ligne pour savoir dans quel ordre les restituer.

Or, si l'intégrité référentielle n'est pas gérée, vous n'avez aucune garantie d'être en capacité de restituer des ensembles cohérents, il peut vous manquer des morceaux à votre insu, ou y avoir des morceaux attribués à tort à un fichier.
L'intégrité des données est l'un des fondamentaux de toute base de données

Citation:

---

Envoyé par user41

Des trous ? C'est à dire ?

---

C'est à dire que les identifiants attribués par le SGBD peuvent par exemple être, dans cet ordre :
1, 2, 6, 4, 7, 8, 9, 11...

• les valeurs 3, 5 et 10 n'existent pas (non commitées, supprimées, "sautées" par intervention sur la variable système auto_increment_offset...)
• la valeur 6 a été insérée avant la valeur 4, car le système de distribution des identifiants fait qu'en environnement multi-utilisateurs, les valeurs d'identifiant ne sont pas toujours insérées chronologiquement

Citation:

---

Envoyé par user41

Je ne dépasserai pas 4 milliards de lignes donc le Int devrait suffire ?! (quelle que soit la taille des lignes)

---

Oui s'il s'agit d'un integer non signé, s'il est signé, il y a un peu plus de 2 milliards de valeurs possibles