Discussion :

[dsr57]

Bonjour à tous,

Je suis débutant sur SQL SERVER et j'ai une question qui va surement paraitre stupide et évidente mais j'ai besoin d'explications.

Je suis chargé de la base de donnée dans ma boite, et je viens de découvrir qu'une table possède 170 colonnes. Je trouve que cela est énorme et je propose de découper la table en plusieurs tables.

Mais on me répond systématiquement pourquoi, qu'elle est l'intérêt d'avoir plusieurs tables. les développeurs ne veulent pas modifier leur programme pour rajouter des jointures.

De plus la plupart du temps, seul une dizaine de colonne sont utilisées par des requêtes SELECT.

Mes questions:
- Le nombre de colonne est-il gênant ?
- Une requête SELECT sur les 10 colonnes les plus fréquentes peut est elle être ralenti du au nombre de colonne ?
- L'idée de créer plusieurs sous - tales est elle judicieuse ?


Je vous remercie par avance

[elsuket]

Bonjour,

je viens de découvrir qu'une table possède 170 colonnes. Je trouve que cela est énorme et je propose de découper la table en plusieurs tables.

ouch, 170 colonnes c'est bien pour obtenir des performances médiocres et une application qui ne peut pas évoluer.

Mais on me répond systématiquement pourquoi, qu'elle est l'intérêt d'avoir plusieurs tables. les développeurs ne veulent pas modifier leur programme pour rajouter des jointures.

Le problème du changement d'habitudes ...

Le nombre de colonne est-il gênant ?

Oui, puisque c'est complètement anti-relationnel, inoptimisable, inadministrable, ce n'est pas souple et pas évolutif

Une requête SELECT sur les 10 colonnes les plus fréquentes peut est elle être ralenti du au nombre de colonne ?

Oui, parce que toutes les données de cette table sont stockées dans les mêmes pages, c'est à dire que vous stockez probablement dans une seule page très peu de lignes de votre table.

Les pages de données représentent un espace 8192 octets, mais avec les informations d'entête de page et la table d'offsets de ligne stockée en fin de page, on peut stocker au maximum 8096 octets.

Donc plus vous ajoutez de colonnes :

- plus vous ajoutez d'octets à votre ligne,
- moins vous pouvez stocker de lignes dans une page,
- plus SQL Server doit lire de pages pour répondre à la requête,
- moins ces pages peuvent rester longtemps dans le cache (<=> RAM),
- plus SQL Server doit lire de pages depuis le disque,
- plus vos temps de réponse sont mauvais puisqu'on estime qu'un accès en RAM est au moins 1000 fois plus rapide qu'un accès disque

L'idée de créer plusieurs sous - tales est elle judicieuse ?

Tout à fait parce que, comme vous le dites, seules 10 colonnes sont lues très souvent, mais surtout, lorsque vous lirez les tables, vous lirez seulement les données dont vous avez besoin, et par les contraintes d'intégrité (clés primaires et étrangères, contraintes d'unicité et de domaine), vous aurez une base de données très consistante et très souple.

Vous ne pouvez faire cela qu'en réalisant un modèle conceptuel de données.
Pour vous aider, vous pouvez commencer avec cet article de SQLPro

Pour obtenir des temps de réponses encore meilleurs, il vous restera à étudier vos requêtes pour indexer vos tables.

Pour vos requêtes, utilisez des procédures stockées : cela présente de nombreux avantages outre la réutilisation de plans et cela vous permettra de fournir une couche d'abstraction complète aux applications.

Bref, vous avez du pain sur la planche.
Bon courage

@++

[agemis31]

Bonjour,

Au vu des éléments que vous nous donnez, il faut découper.

Il faut différencier le problème de design de votre base, du problème de performance.

Si cette base de données est pratiquement toujours accédée en lecture seule, un degré de dé normalisation élevé peut être utile.

Si ce n'est pas le cas, il s'agit probablement d'une mauvaise conception
qui va poser à terme des problèmes récurrents de maintenance, développement, compréhension, ...
Donc si cette base de données et ses applicatifs sont encore
amenés à vivre et à bouger un bout de temps, il me semble judicieux de la renormaliser.

Les bénéfices sur les temps de développement sont à voir sur le terme.
Et rien ne vous empêche de créer une vue en attendant pour minimiser l'impact (en lecture probablement)

http://sqlpro.developpez.com/SGBDR/R...egles_codd.pdf

Quant aux performances, SQL Serveur lit les données par page. Avec 10 informations utiles sur 130, de façon simpliste on est 13 fois plus
lent qu'on ne pourrait l'être. Dans la réalité le gain ne sera pas de 13, mais il sera sans doute sensible.

@+

[dsr57]

Pour commencer merci pour ces réponses et les liens.

J'avais déjà lu l'article sur les index, qui est très intéressant et très bien expliqué.

Merci pour les solutions procédures, et les vues je vais les étudier.

En revanche j'aimerais avoir un plus d'informations sur les pages de données.
En premier lieux pour mes connaissances, en second lieux pour répondre au futur questions de développeurs.

Ou pourrais je trouver un article qui explique le fonctionnement de ces pages ?

Merci par avance.

[SQLpro]

Ici : http://sqlpro.developpez.com/optimis...ntenanceIndex/

A +

[dsr57]

super cet article, il permet de comprendre énormément de chose.

J'aurais encore quelques questions :

- Les procédures stockées, j'ai lu une fois dans un article qu'elle était plus couteuse. elle effectue plus de lecture sur la base. je n'arrive pas a retrouver cet article.
Est ce juste ? Y-a-t il des normes a respecter pour les optimiser ?

- Les index, j'ai lu deux articles. Un premier sur les index, ou ils disent que lemieux c'est d'avoir un index couvrant, et le deuxième article dit que les index sur une colonne sont mieux pour éviter une forte fragmentation.
Comment choisir la meilleur solution. Cela dépend t -il des cas ?

Merci par avance

[SQLpro]

- Les procédures stockées, j'ai lu une fois dans un article qu'elle était plus couteuse. elle effectue plus de lecture sur la base. je n'arrive pas a retrouver cet article.
Est ce juste ? Y-a-t il des normes a respecter pour les optimiser ?

Ceci est totalement faux et parfaitement stupide...
Il n'y a rien de plus performant naturellement que les procédures stockées...
Je vais faire paraître un article dans quelques mois consacré au développement pas de données épais qui montre bien que c'est grâce aux vues, aux triggers INSTEAD OF et aux procédures stockées que l'on peut obtenir les performances les plus extrême et de surcroit en diminuant le temps de développement d'une facteur de 2 à 4 !

- Les index, j'ai lu deux articles. Un premier sur les index, ou ils disent que le mieux c'est d'avoir un index couvrant, et le deuxième article dit que les index sur une colonne sont mieux pour éviter une forte fragmentation.
Comment choisir la meilleur solution. Cela dépend t -il des cas ?

Il n'y a pas de meilleur index. Il y a des index adéquat pour répondre à une problématique précise.
Il n'y a donc qu'une seule règle à suivre : mesurer l'impacte de l'indexation sur vos requête face à une vraie volumétrie.... pas quelques lignes mais quelques centaines de milliers voir plusieurs millions, bref, un volume proche de la réalité de ce que sera la base dans 3 à 5 ans....

A +