Livre SQL Server 2014 (Frédéric Brouard, Christian Soutou, Nicolas Souquet et David Barbarin)

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/04/2015, 16h57
julien94320
Bonjour,

Pour avoir lu le livre du début jusqu'a la fin ( j'ai même lu quelques pages plusieurs fois :aie: ... ) ce bouquin est génial !

C'est le bouquin à avoir sous le coude tout le temps :
- Il sera utile pour les étudiants voulant comprendre le fonctionnement d'un SGBD tel que SQL Server, il permettra de comprendre les rudiment de la modélisation
- Il sera utile pour les développeurs en remettant en cause certaines fausses bonnes idées aquise au quotidien et levera le voile sur le comportement de certaines parties "obscure":weird:
- Il sera utile pour les DBA's en consolidant les aquis et en révisant certaines idées pré conçus
Bref c'est un bouquin à lire, apprendre et à avoir constament a porté ;).

Julien

Ps

Je ne suis pas rémunéré pour ce commentaire plus qu'élogieux et méritant :lol:
09/04/2015, 09h34
SQLpro
Citation:
Envoyé par julien94320

Bonjour,

Pour avoir lu le livre du début jusqu'a la fin ( j'ai même lu quelques pages plusieurs fois :aie: ... ) ce bouquin est génial !

C'est le bouquin à avoir sous le coude tout le temps :

Il sera utile pour les étudiants voulant comprendre le fonctionnement d'un SGBD tel que SQL Server, il permettra de comprendre les rudiment de la modélisation
Il sera utile pour les développeurs en remettant en cause certaines fausses bonnes idées aquise au quotidien et levera le voile sur le comportement de certaines parties "obscure":weird:
Il sera utile pour les DBA's en consolidant les aquis et en révisant certaines idées pré conçus

Bref c'est un bouquin à lire, apprendre et à avoir constament sous le coude ;).

Julien

Ps

Je ne suis pas rémunéré pour ce commentaire plus qu'élogieux et méritant :lol:
Comme vous l'avez trouvé bien, n'hésitez pas à nous faire un peu de pub sur Amazon ou fnac, en particulier si vous l'avez acheté sur l'un de ces sites !

A +
09/04/2015, 12h00
elsuket

Merci pour votre retour d'impressions julien94320 !

@++ ;)
06/09/2015, 15h36
alassanediakite

Salut
Heureux de vous annoncer que j'ai eu le mien ce matin.:yaisse2:
Mais comment comprendre que QUATRE experts en bases de données, oublient l'INDEX?:scarymov:
@+
06/09/2015, 16h54
hmira

Citation:

Envoyé par alassanediakite

Salut
Mais comment comprendre que QUATRE experts en bases de données, oublient l'INDEX?:scarymov:
@+

Non l'index n'a pas été oublié !
L'index du livre se trouve, à la fin, dans le complément du livre (366 pages à télécharger). Le lien pour le téléchargement est indiqué sur la couverture du livre.

L'index du livre est constitué de 19 pages ! (de la page 1187 à la page 1205 incluses).

Bonne lecture ..

A+
06/09/2015, 19h24
SQLpro

Citation:

Envoyé par alassanediakite

Salut
Heureux de vous annoncer que j'ai eu le mien ce matin.:yaisse2:
Mais comment comprendre que QUATRE experts en bases de données, oublient l'INDEX?:scarymov:
@+

Je t'avoue que j'aurais préféré qu'il figure dans la partie papier du livre...

A +
08/09/2015, 07h25
elsuket

On va faire en sorte qu'il soit dans le livre sur SQL Server 2016 ;)

@++ ;)
28/05/2016, 15h26
alassanediakite

question et remarque

Salut
Une question...
A la page 562, paragraphe "Bonnes pratiques en matière de sécurité". Pour la ligne... "Créer autant de comptes de connexion et d'utilisateurs SQL en fonction du nombre de groupes d'utilisateurs fonctionnels dotés de différents profils. Veillez à ne pas en créer trop (moins d'une dizaine)."
Dois-je comprendre que quelque soit le nombre de personnes devant se connecter à la base, de créer au plus dix comptes serveurs et dix utilisateurs au niveau base de données?
______

Une remarque...
Je constate une contradiction entre une remarque (l'encadré) à la page 298 et une autre à la page 317.
La remarque concerne "la ligne affectée à des variables lors d'un SELECT INTO avec plusieurs lignes".

Merci d'avance pour toute réponse.
@+
02/06/2016, 06h31
Bernardos

Bonjour,
je viens (enfin) de recevoir ce petit bijou.
malheureusement, j'ai beau cherché sur le site mentionné. je ne trouve pas de lien vers la 5ème partie, les annexes et les exemples.
quelqu'un pourrait-il me guider?
Merci d'avance
Loïc
02/06/2016, 15h08
SQLpro

Citation:

Envoyé par lbernard

Bonjour,
je viens (enfin) de recevoir ce petit bijou.
malheureusement, j'ai beau cherché sur le site mentionné. je ne trouve pas de lien vers la 5ème partie, les annexes et les exemples.
quelqu'un pourrait-il me guider?
Merci d'avance
Loïc

http://blog.developpez.com/sqlpro/p1...urces-du-livre

A +
02/06/2016, 19h29
alassanediakite

la place du gestionnaire de tri
Salut
Une question (bien qu'on semble m'ignorer royalement)...
Vu...
- le rôle du moteur de stockage, qui est de remonter des pages du disque à la RAM ou inversement
- le rôle du moteur de requête qui est de traiter une requête et de retourner les lignes résultats (triées si besoin) vers le client
- par ailleurs, certains traitements (tels les fonctions de fenêtrage) nécessite un tri en mémoire
la place du gestionnaire de tri n'est pas plutôt vers le moteur de requête que vers le moteur de stockage?
Pour toute réponse, merci d'avance .
@+
03/06/2016, 09h50
SQLpro

Erreur courante de penser cela...
En effet le tri est une opération physique et cosmétique destinée à présenter les lignes de la table résultante ou à créer un index.

En revanche le moteur relationnel peut être amené en certaines circonstance a effectuer un tri logique pour des raisons de performances à la place d'un autre algorithme.
Un petit exemple...
un GROUP BY peut être réalisé par des techniques différentes : tri ou hachage.
Si les éléments du GROUP BY apparaissent dans un index alors il pendre très certainement l'algo de tri parce que les données sont déjà triées dans l'index. Autrement dit il ne fera que "lire" l'index.
S'il n'existe pas d'index il y a de fortes chances qu'une opération de hachage soit enteprise
La troisième solution est de faire un tri logique, si la clause GROUP BY ne concern que peu de colonnes (en général ) et peu de lignes....

Il e est de même pour le ORDER BY des clauses OVER; car souvent elles sont accompagnées de PARTITIONS....

Ne pas oublier que l'algèbre relationnelle est basée sur une logique ensembliste dans laquelle la notion d'ordre ou de tri des données n'existe nulle part. Une table étant un sac (de bille !).

A +
03/06/2016, 10h31
Bernardos

merci pour le lien :)
03/06/2016, 18h26
alassanediakite

Salut
Merci pour l'explication. Je vais chercher à le comprendre.
@+
16/06/2016, 15h50
hmira

Citation:

Envoyé par SQLpro

Ne pas oublier que l'algèbre relationnelle est basée sur une logique ensembliste dans laquelle la notion d'ordre ou de tri des données n'existe nulle part. Une table étant un sac (de bille !).

Oui, tu as complètement raison concernant, l'algèbre relationnelle et plus généralement les opérations ensemblistes usuelles que sont Union, Intersection, Différence, Produit Cartésien, etc. qui ignorent effectivement toute notion d'ordre.

Mais, pouvons-nous toutefois rappeler que l'algèbre relationnel est une théorie mathématique très proche de la théorie des ensembles ou du moins elle s'en inspire très fortement.

Une relation est par essence définie comme un sous ensemble de produit cartésien de deux ou plusieurs ensembles où les dits ensembles ne sont autres que les domaines où les colonnes puisent leurs valeurs respectives.
Donc, selon la théorie des ensembles, une relation est finalement un ensemble comme un autre.

Dans la théorie des ensembles, contrairement à l'algèbre relationnel, la notion de "Ensembles ordonnés", de "Relation d'ordre total" ou de "Relation d'ordre partiel" sont clairement définies.

Sous SQL Server la prise en compte ou l'impact de la "Collation" ainsi que d'autres considérations purement techniques voire même physiques, font que, d'après mon analyse, le tri (ORDER BY) ou l'agrégation 'GROUP BY" etc. se rapprochent davantage de la notion de "Relation d'ordre total" de la théorie des ensembles.

En d'autres termes, dès lors que l'on définit une clause ORDER BY ou une clause GROUP BY, Celle-ci établie intrinsèquement, en fonction de la Collation et autres considérations techniques, au sens purement mathématique de la théorie des ensemble, une "relation d'ordre total", sur l'ensemble, c.à.d. la relation sur laquelle elle s'applique.

Ci-dessous deux articles que j'ai publiés sur mon blog perso. traitant des mathématiques et de la théorie des ensembles, en lien directs avec notre discussion.

Théorie des ensembles : Ensemble, Produit cartésien, Relation
http://hamid-mira.blogspot.fr/2012/0...apitre-01.html

Théorie des ensembles : Ensembles bien ordonnés
http://hamid-mira.blogspot.fr/2012/0...apitre-02.html

A+
18/09/2018, 18h42
fsmrel

Ave,

Citation:

Envoyé par hmira

Dans la théorie des ensembles, contrairement à l'algèbre relationnel, la notion de "Ensembles ordonnés", de "Relation d'ordre total" ou de "Relation d'ordre partiel" sont clairement définies.

Dans ses articles fondateurs de 1969, Derivability, Redundancy and Consistency of Relations Stored in Large Data Banks et 1970 A Relational Model of Data for Large Shared Data Banks, Ted Codd ne nomme pas explicitement les attributs, il tient donc compte de leur ordre (cf. l’opération de permutation). En 1971, ouf ! il donne un nom à chaque attribut d’une relation (cf. A Data Base Sublanguage Founded on the Relational Calculus ou Further Normalization of the Data Base Relational Model), et exit la permutation. Ainsi la différence entre les relations au sens mathématique et au sens du modèle relationnel est définitive, voir The Relational Model for Database Management, Version 2, Table 1.1, page 4.
19/09/2018, 10h10
hmira

Bonjour fsmrel,

Je suis toujours ravi de lire vos commentaires.

Vous faites semble-il allusion à l'ordre des "attributs" d'une relation (?). L'ordre des attributs est un concept aussi intéressant, mais rarement abordé ou étudié.

L'attribut étant défini comme une "colonne" d’une relation caractérisée par un nom. On insiste souvent sur le nom d'un attribut, sur le domaine d'un attribut, mais rarement sur l'ordre d'un attribut.
Les liens que vous nous avez indiqués vont surement nous éclairer davantage sur ce sujet.

Dans mes propos, que vous avez cités, je ne parlais pas de l'ordre des attributs, mais de l'ordre, s'il doit être défini, de l'ensemble des "tuples" d'une relation.
Une "relation" étant définie comme un sous-ensemble du produit cartésien d’une liste de domaines caractérisé par un nom.

Le modèle relationnel, peut finalement être perçu comme un modèle mathématique simple des données.

Merci pour les liens, très instructifs, que vous nous avez indiqués.

A+
23/09/2018, 00h00
i.chafai

Bonjour,
Malheureusement je n'arrive pas a avoir le livre (impossible de faire payer en international de la Tunisie)
Pour les membres Tunisien, connaissez vous ou pourrais-je le trouver ?

Merci par avance
24/09/2018, 15h40
SQLpro

Citation:

Envoyé par i.chafai

Bonjour,
Malheureusement je n'arrive pas a avoir le livre (impossible de faire payer en international de la Tunisie)
Pour les membres Tunisien, connaissez vous ou pourrais-je le trouver ?

Merci par avance

Tu peut le commander dans une librairie tunisienne, ça mettra du temps !

A +
25/09/2018, 00h03
i.chafai

Citation:

Envoyé par SQLpro

Tu peut le commander dans une librairie tunisienne, ça mettra du temps !

C'est ce que j'ai fait, avec un prix *2 8O et je vais le recevoir dans 2 mois 8O8O

Voir 40 message(s) de cette discussion en une page