Discussion :

[ernestomaja]

Bonjour,
J'ai acheté le livre "SQL Tête la première" de O'REILLY. Le livre fait référence à un site "tetelapremiere.fr" qui offre les fichiers d'exercices en téléchargement. Ce site n'existe plus.
Quelqu'un pourrait-il me transmettre ces fichiers ? Merci d'avance ...

[SQLpro]

O'Reilly france ayant arrêté ses activités il est probable que vous ayez beaucoup de mal à trouver ce que vous cherchez...

Mieux vaudrait vous rabattre sur un éditeur et un livre un peu plus sérieux... comme le mien !

A +

[johnny3]

O'Reilly france ayant arrêté ses activités il est probable que vous ayez beaucoup de mal à trouver ce que vous cherchez...

Mieux vaudrait vous rabattre sur un éditeur et un livre un peu plus sérieux... comme le mien !

A +

Je ne trouve pas sympa de dénigrer un livre de cette qualité (ni même un éditeur de la qualité d'Oreilly). J'ai acheté votre livre, mais j'ai trouvé des choses très agréables dans le livre de tête la première que je n'ai pas retrouvées dans le vôtre. Heureusement, la plupart des ouvrages sont complémentaires

[johnny3]

Bonjour,
J'ai acheté le livre "SQL Tête la première" de O'REILLY. Le livre fait référence à un site "tetelapremiere.fr" qui offre les fichiers d'exercices en téléchargement. Ce site n'existe plus.
Quelqu'un pourrait-il me transmettre ces fichiers ? Merci d'avance ...

Facile, il suffit d'aller sur le site O'Reilly américain pour les télécharger en anglais. Sinon, si vous attendez un peu, ellypse les mettra sûrement en ligne (ils ont acquis les droits pour publier 200 ouvrages O'Reilly. Espérons que des livres de la qualité tête la première en feront partie)

Et, sinon... j'avais téléchargé tous les fichiers à l'époque, quand la nouvelle est tombée. Je peux vous les envoyer.

[SQLpro]

Je ne trouve pas sympa de dénigrer un livre de cette qualité

Je ne pense pas l'avoir dénigré. En effet la série tête la première propose une approche ludique, c'est à dire amusante... Je ne dénigre donc pas du tout quand je parle de mon livre en disant qu'il est sérieux, en effet mon ouvrage n'est ni ludique, ni amusant et je suppose que vous ne l'avez pas lu puisque vous affirmez des choses fausses....
Quant à la cessation d'activité de O'Reilly France, je n'y suis pour rien. Il y a partout dans le monde des entreprises qui arrêtent parce que l'on a beau être de très haut niveau, ce niveau de fait pas vendre (exemple Rolls Royce). Pour gagner des sous dans cet univers (celui du livre français d'informatique) il faut soit avoir un mécène (cas des éditions MS Press par exemple), soit publier des collections de plus bas niveau (comme le font Eyrolles ou Dunod).

A +

[MaitrePylos]

En effet la série tête la première propose une approche ludique, c'est à dire amusante...

Je pousserais même jusqu'a parler de pédagogie par projet.

Ce qu'il ne faut pas confondre dans les deux livres qui vous occupent, c'est que l'un est une introduction au langage SQL pour débutant, et l'autre un ouvrage de référence en la matière.

Ayant lu les deux livres et travaillant quotidiennement avec DB2, je vous laissent deviner quel est le livre que je parcours tous les jours

[ernestomaja]

Merci pour vos réactions. J'ai demandé par mp les fichiers à johnny3.
Pour ma part, ayant déjà acheté quelques livres sur SQL, je trouve que le "Tete la première" est très pédagogique ... et c'est ce qui me convient, pour le moment.

[Nonoleplongeur]

merci Johny pour les infos, voici le lien sur le site Américain , malheureusement le code ne correspond pas à celui de la version Française tant sur les exemples en Anglais sur les portions de code. Voici quand même le lien pour ceux que ça intéresse ( valable le 15/02/09)

http://www.headfirstlabs.com/books/hfsql/

Pour ma part, je trouve ce livre excellent pour une introduction en la matière et pour ce forcer un peu à travailler. Une simple lecture ne suffit pas pour ce type d'apprentissage, il faut de la pratique et c'est exactement ce que ce livre propose.

Bon dév à tous,

Arnaud

[zorglub1970]

merci Johny pour les infos, voici le lien sur le site Américain , malheureusement le code ne correspond pas à celui de la version Française tant sur les exemples en Anglais sur les portions de code. Voici quand même le lien pour ceux que ça intéresse ( valable le 15/02/09)

http://www.headfirstlabs.com/books/hfsql/

Pour ma part, je trouve ce livre excellent pour une introduction en la matière et pour ce forcer un peu à travailler. Une simple lecture ne suffit pas pour ce type d'apprentissage, il faut de la pratique et c'est exactement ce que ce livre propose.

Bon dév à tous,

Arnaud

pour information les livres oreilly sont disponibles en pdf sur le site
http://librairie.immateriel.fr/fr/eb...-premi%C3%A8re

[vduvernet]

un peu de nécro-posting ^^

Le sujet tombe à pic (avec 4 ans d'avance en fait ;p)

Je lis actuellement Tête la première - Analyse et Conception OO histoire de se remettre à un peu à jour. (Dunod semble avoir acquis certains droits à en juger leur site mais pas sur cet ouvrage).
(Je ne dis pas que je n'irais pas jeter un oeil à celui d'SQLPro plus tard mais je n'en suis pas là pour le moment).
Comme je viens de finir C# 5, j'essaye de faire des parallèles entre les 2 bouquins.

Et justement dans tête la première, page 31 (voir topic http://www.developpez.net/forums/d88...tete-premiere/), l'auteur préfère sortir de la classe Guitare des critères de recherche de guitare (comme le fabriquant, modèle, type...).
En gros, il encapsule toute caractéristique dans une classe dédiée afin de pouvoir ajouter des critères par la suite, pourquoi pas.

Mais d'un point de vue BDD, cela veut-il dire qu'il faut aussi avoir 2 tables distinctes ? une T_Guitare et une T_PrefGuitare avec un lien entre les 2 deux ? (surtout si on veut utiliser EntityFramework par la suite (pas encore testé mais cela a l'air sympa)

Qu'en disent les gourous des BDDs ?

Merci.

[SQLpro]

Et justement ... l'auteur préfère sortir de la classe Guitare des critères de recherche de guitare (comme le fabriquant, modèle, type...).
En gros, il encapsule toute caractéristique dans une classe dédiée afin de pouvoir ajouter des critères par la suite, pourquoi pas.

Mais d'un point de vue BDD, cela veut-il dire qu'il faut aussi avoir 2 tables distinctes ? une T_Guitare et une T_PrefGuitare avec un lien entre les 2 deux ? (surtout si on veut utiliser EntityFramework par la suite (pas encore testé mais cela a l'air sympa)

Qu'en disent les gourous des BDDs ?

Merci.

En matière de modélisation de bases de données, il n'y a pas de classes ! Mais des relations, qui sont des objets porteurs de données (et non comme on le voir trop souvent écrit par des imbéciles, des liens entre les table !!!) (voir la définition du Larousse sur le terme RELATION : "Action de rapporter en détail ce dont on a été le témoin ou dont on a eu connaissance ; récit qu'on en fait : Faire la relation des événements auxquels on a participé." )

Le but de la modélisation est d'obtenir globalement les meilleurs performance en appliquant des règles strictes (formes normales), qui peuvent être globalement résumées par :
1) éviter toute redondance (sinon : augmentation du volume des données, multiplication du coût des mises à jour, possibilité de dédoublement d'information...)
2) éviter du stockage inutile, donc éviter le NULL (sinon : augmentation du volume des données pour des données non significative)
3) éviter que la mise à jour d'une information impacte plus d'une ligne (sinon multiplication ... du coût des mises à jour, de la durée des blocages, etc)
4) éviter de stocker des données non atomique (leur décomposition nuit aux performances à tous les niveaux : lectures comme écritures, car il est difficile voire impossible d'y poser des index)
ETC.

On peut alors parfaitement comprendre que certaines guitares n'aient pas de fabriquant, modèle ou type...
On peut aussi comprendre qu'alourdir une table avec des colonnes qui ne seront utilisée que par 3% des requêtes, face à une table qui aura 97% des requêtes concernant les guitares pose immanquablement le problème des performances. En effet, toute augmentation de degré (nombre de colonnes d'une table) entraine fatalement une diminution des performances, car les accès aux données se font par des pages contenant des lignes, c'est à dire TOUTES les colonnes de la table (même si je dois n'en lire qu'une seule !!!)....

A +

[vduvernet]

Ok, je vois ton point de vue sur les performances liées aux Lignes / Colonnes.
Mon projet envisage 50 000 enregistrements, ce n'est pas forcément énorme mais ce n'est pas une raison pour coder comme un gruiccckkkk.

Le fait de sortir des critères 'optionnels', ça pousse à décomposer encore davantage. Par exemple, si on remplit l'année de création, on peut avoir envie de fournir l'année de fin de production. Par contre, on peut ne pas forcément avoir l'information sur le type de cordes d'origine. Donc il faudrait décomposer cela en 2 ?

Concernant la modélisation, justement, c'est le lien entre les 2 qui m'interroge. Entity Framework semble être sympa pour mapper des données dans des classes C#.
Comme mon projet perso n'en est qu'à l'étude préalable afin d'adapter une pré-version faites en Access 2013 trop limitée, je voudrais bien partir dans la bonne direction au début du chemin ;p

Vincent

[MaitrePylos]

La lecture de l'article suivant http://fsmrel.developpez.com/basesre...normalisation/ te permettras de comprendre au mieux ce que te dis @SqlPro.
Je pense que tu pourrais assimiler jusqu'a la 3FN, tu auras déjà un bon point de départ.

De plus tu ne dois pas confondre les outils que t'offre C# et le SQL Pure, une bonne modélisation sans passer par une abstraction de la db (Entity), te garantiras de meilleurs perfs.

[vduvernet]

Yop,

bon j'avoue, j'ai fini par décrocher en cours de lecture. C'est un énorme travail de rédaction et de recherche de sources. (Parfois, j'ai trouvé des sections assez imbuvables à se demander si un excès de caféine n'avait pas engendré la rédaction de phrases peu parlantes pour une majorité d'humanoïdes).

J'y ai trouvé des parties intéressantes sur l'espace alloué, les benchmarks qui sont des retours intéressants et bien entendu toute la partie redondance.
Pour le moment, c'est encore flou pour adapter la théorie à la pratique.

Ah si, j'ai bien aimé les retours d'expérience sur les banques. ^^

J'ai noté une question tout de même :
page 52 du PDF : pourquoi le chèque a l'ID de remise et l'ID de lot alors que par transitivité, on choppe l'id du lot par la remise ? N'est ce pas une redondance ?

(je vais refaire le tour de mon analyse de BDD pour vérifier. J'utilise beaucoup d'ID un peu partout donc j'ai peut-être éviter les redondances spontanément.)