Babillard - Optimisation de la base de données

.
22.3. Avoir besoin de comprendre pourquoi, n'est pas un problème du tout. Seuls les enfants suivent aveuglément des règles simples, et vous n'êtes certainement pas l'un d'entre eux.
.
23. Confirmé :users.total_bulletins est redondant ; il peut être dérivé. Supprimé.
.
24. Tous vos PK sont des identifiants. Vous n'en avez pas encore marre de vous perdre dans le code ? Oubliez de coller Id iot PKs sur tout ce qui bouge, découvrons comment vos utilisateurs Identifier leurs Entités ; quelles entités sont véritablement indépendantes, et les autres qui dépendent d'entités indépendantes.

24.1. Ne jamais utiliser Id ou une telle forme. S'il s'agit d'un PK, utilisez le formulaire complet.

24.2. Appelez location_id, location_id, où qu'il se trouve, y compris la table PK. L'exception est lorsque vous devez afficher le rôle. Cela deviendra clair dans le modèle de données.
.
25. Vous n'avez pas d'intégrité référentielle déclarative, pas de définie Clés étrangères. C'est une mauvaise nouvelle pour de nombreuses raisons différentes. Une fois ces questions clarifiées, veuillez les ajouter. DRI signifie que dans la mesure du possible, sinon la totalité, l'intégrité est déclarée en SQL. La norme ISO/IEC/ANSI SQL permet cela, mais la partie gratuite du marché ne fournit pas la norme et rattrape lentement son retard. Cela signifie que le serveur n'autorisera pas l'ajout d'une ligne dans la table FK à moins que la PK n'existe dans la table parent. MySQL a récemment fourni DRI pour les clés étrangères. Pour les FK, reportez-vous à ▶ cet article◀ .

25.1. Pour les contraintes CHECK et RULES, vous devrez les implémenter dans le code.

mes clés étrangères sont comme, users-id(fk) =users.id(pk) Je ne sais pas comment les ajouter autre que ce que j'ai fait mais je le ferai certainement une fois que je saurai comment le faire.

Vingt cinq. Commentaires notés. Je ne suis pas un spécialiste de MySQL. Oui, ce sont les problèmes que vous devez résoudre par vous-même. En général, d'après ma lecture, MySQL est sans jambes; pour tout ce qui concerne SQL, vous avez besoin d'InnoDB.

.
27. Donné :J'ai repensé les exigences de tri pour le bulletin. Les utilisateurs peuvent trier par ordre chronologique - facile, logique. Les utilisateurs peuvent trier les bulletins en fonction de la date de la dernière réponse au bulletin. Ensuite, nous pouvons oublier le classement et il devrait être vraiment facile de trier les bulletins chronologiquement au moment de leur dernière réponse ? Quelles sont vos pensées.

Problèmes ouverts

(Nul)

Modèle de données

Ok, en supposant que vous n'ayez pas de problèmes avec l'ERD, et en mettant en œuvre tous les problèmes fermés, j'ai modélisé les données et préparé un Cinquième modèle de données 09 décembre 10 pour votre avis. J'ai définitivement besoin de beaucoup plus commentaires, questions, etc. à ce sujet. J'ai du mal à accepter que ce soit fait. Il est probablement préférable de commencer à écrire du vrai code pour vos problèmes.

Liens

▶Lien vers la notation IDEF1X◀ Vous devez vraiment lire et comprendre ceci avant de lire le modèle de données.

▶Lien vers les données du cinquième bulletin Modèle◀ Le Diagramme Entité-Relation se trouve sur la première page, suivi du modèle de données .

• Les clés sont à peu près droites IDEF1X (sauf pour UserId que j'ai fourni en contrepoint) ; ce qui signifie porte-monnaie clés relationnelles. Non amélioré et non optimisé pour des considérations physiques. Avant de les hésiter, remarquez-les d'abord, enregistrez-les et évaluez-les. Bien sûr, nous pouvons ajouter Id iot keys, mais avant cela, assurons-nous de comprendre ce que nous allons perdre.

• Notez les identificateurs (lignes pleines) selon le document Notation. La colonne vertébrale, les vertèbres du système est Location ... Bulletin ... Response .

• Notez que les clés implémentent en fait de nombreuses règles métier.

• Remarquez la Hiérarchie Naturelle que j'ai rendue. Voyez s'il y a une signification pour vous.

• Les VerbPhrases sont vraiment importants; voyez s'ils signifient quelque chose.

Commentaires concernant le premier modèle de données et les réponses

Une question que j'ai est que la clé primaire de l'emplacement sera utilisée pour former la clé primaire enfant ? (elles sont reliées par une ligne continue) Je ne comprends pas vraiment ce concept

• Qu'est-ce qu'un bon identifiant pour Bulletin ? , qu'est-ce que vos utilisateurs utilisent naturellement pour identifier un bulletin ...
• "avez-vous vu le bulletin de Virginie FO hier ?",
• "Sally de Washington écrit de bons bulletins", etc.

ou pourquoi cette relation n'existe pas entre l'utilisateur et le bulletin ?

• Conformément à l'intention indiquée ci-dessus, puisque j'ai maintenant montré la note sous forme de tableau et ce que serait le rendu, une fois, je la supprimerai

• Je pense que l'autorisation devrait être une entité.

• Bulletin PK est maintenant (StateCode, Town, UserId, SequenceNo) . Pour être clair, SequenceNo est dans StateCode, Town, UserId :ce sera 5 pour le 5ème bulletin de Sally concernant MO/Billngs FO.

• Notez que les paramètres utilisateur BulletinsPerPage ,etc, sont 1 ::1 avec User , ils sont donc dans User; la table enfant serait incorrecte.

• Erreurs typographiques corrigées.

Commentaires concernant le deuxième modèle de données et les réponses

• Les PK pour les deux Bulletin et Response ont été modifiés pour refléter (7). BulletinNo et ResponseNo ont été remplacés par BulletinDate et ResponseDate (qui était auparavant CreatedDate ), afin de permettre plusieurs réponses par User par Bulletin .

Commentaires concernant le troisième modèle de données et les réponses

J'espère que vous avez passé une bonne pause.

1. Il y a au moins 30 ans (à ma connaissance), les géants de l'industrie avaient ce débat. Les noms sont toujours au singulier. Les tableaux sont des noms. VerbPhrases sont des verbes. Cela ne se limite pas aux conventions de dénomination db, cela s'applique aux documents, thèses, mémoires, etc. Vous pouvez avoir 5 conclusions à la fin du document, mais le titre de la section ou du chapitre, à la fois dans la table des matières et en haut de la page est "Conclusion".

   Après les avoir combattus tout au long de l'université, dès que j'ai commencé mon premier travail de programmation rémunéré et que j'ai vu l'importance des règles dans le monde réel, par opposition aux arguments théoriques que nous avions à l'université, j'y ai renoncé comme un gâchis de temps. Tout ce temps et cette énergie que j'ai gaspillés ont été libérés pour faire un travail productif. Depuis, je ne remets plus en cause les géants; J'accepte juste. Que leur esprit est plus grand que le mien. C'est comme accepter les Normes, ou se comporter selon la loi, ou Dieu. Je n'ai pas vraiment de bonnes raisons de faire quoi que ce soit d'illégal.

   Quoi qu'il en soit, la facilité de langage (discussion, SQL, documentation) qui est supportée par de telles règles ne peut pas être expliquée de manière adéquate; au fur et à mesure que vous écrivez du code SQL, cela deviendra clair.

   Vous êtes toujours libre d'utiliser ce que vous voulez. Je livre uniquement au singulier.

2. Cela me convient.

   Mais vous devez garder à l'esprit que ces deux éléments, dans la séquence identifiée (ala non-PK Unique Index, ou Alternate Key) sont universellement requis pour établir l'unicité d'une personne. Les supprimer entraînera deux choses. Tout d'abord, vous ne pourrez plus identifier l'unicité entre les Users (et donc vous pouvez avoir des lignes en double). Deuxièmement, l'AK devient non unique, une entrée d'inversion.

3. Le point est (contrairement à l'un des messages), toute colonne qui est 1 ::1 avec le User PK, doit résider dans User . Tous les paramètres de préférence. Depuis que nous avons nettoyé les InterestedLocations et InterestedCategories , je ne connais que BulletinsPerPage restant; mais je suis sûr qu'il y en a d'autres. IsPreference2 est un ex. d'un booléen ;NumPreference3 est un ex. d'un entier. Etc. Vous pouvez me dire quelles sont les vraies préférences.

   (Essayons cela au pluriel :... toute colonne qui est 1 ::1 avec les Users PK, doit résider dans Users . Cela ne me convient tout simplement pas, je m'accroche à l'anglais approximatif et je suis un peu précieux pour ma langue maternelle.)

   Modèle de données mis à jour.

4. Excellent. Faites-moi savoir quand vous serez à l'aise avec cela, et je vous donnerai le modèle physique.

   Et les VerbPhrases ?

Commentaires concernant le 06 décembre 10 à 20h38 HNE (petites mises à jour)

.
28. Lorsqu'il n'y a qu'une seule occurrence de PK en tant que FK, bien sûr, le nom de la colonne FK est le même que le nom de la colonne PK. Cependant, lorsqu'il y a plus d'une occupation du FK (consultez ResponseRating ), il y a trois UserIds ), nous devons les différencier. Dans la terminologie IDEF1X, cela s'appelle des rôles. Le rôle de l'User qui a publié le Bulletin est Issuer , etc. Évidemment, il est préférable d'utiliser ce nom et de le garder cohérent dans toute la hiérarchie (et non UserId dans Bulletin puis quand nous arrivons à Response , où il y en a deux, et qu'une différenciation est exigée, remplacez-la par IssuerId . J'ai pensé que vous pourriez avoir un problème avec cela; dans les premières étapes, l'utilisation est Issuer.UserId pour qu'il soit absolument clair qu'il s'agit de UserId en tant que FK, et le rôle est Issuer; lorsque nous arrivons au modèle physique, il est simplifié en IssuerId .

De même, nous avons de nombreuses colonnes DateTime (Date en abrégé si vous préférez ; sinon Dtm), qui doivent être différenciées.
.
29. La notation IDEF1X n'avait-elle pas de sens?

• Le PK pour chaque table est au-dessus de la ligne, dans l'ordre spécifié.
• N'oubliez pas que nous transportons de toute façon les PK des tables parentes, et si cela a un sens, utilisez ces FK pour former la PK enfant.

• Pour Bulletin :

  • L'emplacement FK (StateCode, Town) pour lequel il est délivré
  • Le UserId de l'Émetteur
  • et la date et l'heure de son émission, pour le rendre unique.
  • donc (StateCode, Town, IssuerId, BulletinDate)`

• Pour supprimer tous les ResponseRatings pour ce Bulletin , utilisez WHERE = sur ces quatre Bulletin Colonnes.

.
30. Parce que (State, Town) est le PK de Location , emportant partout. Et il fait partie du Bulletin PK, donc toutes les tables dépendantes portent ces colonnes car elles portent le Bulletin PAQUET.

Nous avions précédemment identifié ce (State, Town) est le PK, je vais le laisser tel quel Reportez-vous à (38) pour le changement.

.
33. Vaut la discussion. Oui, si vous comptez l'afficher lors (par exemple) de l'affichage des Responses , et les utilisateurs comprennent UserName . Non, s'il s'agit de 30 octets et qu'il existe également un UserId unique de 4 octets . L'idée est de faire ces choix consciemment, conscient de ce que vous renoncez, lorsque vous décidez finalement qu'une clé de 6 colonnes de 30 octets est trop lourde pour migrer vers les enfants.

• J'ai indiqué au départ que j'utiliserais UserId comme un Id typique Pk, car il est transporté/migré vers plusieurs tables enfants.
• Nous pouvons laisser la façon dont cela est créé pour plus tard. Mais c'est un pur Surrogate PK.

.
34. Aucun problème. Category l'a déjà. Je vais modifier la Order à ListOrder .

.
35. Bien sûr. D'après ce que j'ai lu et entendu, j'en suis plutôt satisfait. Mais j'aimerais plus d'allers-retours pour gagner en confiance, avant d'écrire du code. Sinon, considérez-le comme une expérience d'apprentissage et acceptez que le modèle et le code puissent changer ultérieurement. Voudriez-vous que je produise le Physique maintenant ? Si vous me donnez toutes les corrections, je publierai la prochaine version. J'attends des préférences dans User . Parcourez également rapidement les fonctions et vérifiez que vous disposez de toutes les colonnes dont vous avez besoin.

Regardez certaines des autres réponses, dans un but d'apprentissage et d'intérêt.

.
36. Se joint. Vous venez de rejoindre le quatre trois colonnes au lieu d'une. SQL est lourd avec les jointures, et la nouvelle syntaxe qui était censée faciliter les choses est en fait plus lourde. Mes codeurs n'écrivent jamais de jointures :nous économisons du temps et des fautes de frappe. J'ai un proc qui, étant donné deux tables ou plus, générera le code avec toutes les colonnes et les jointures. Je ne connais pas assez MySQL pour convertir cela pour vous.

Modèle de données mis à jour.
.

Commentaires concernant le 08 décembre 10 à 20h49, quatrième modèle de données et réponses

.
Vérifiez la section précédente juste au-dessus, il y a de petites mises à jour.

IDEF1X :Votre vitesse est correcte.

Notez l'enfant toujours "hérite" du parent PK, en tant que FK (ligne pleine ou discontinue), sinon il n'y a pas de relation entre eux. En utilisant ces colonnes qui existent de toute façon dans l'enfant, pour former le PK enfant, nous portons le sens (et c'est la différence entre solide et cassé). Et ainsi nous n'avons pas besoin de chercher un identifiant indépendant pour l'enfant. Le pouvoir relationnel de cette méthode deviendra clair plus tard, lorsque vous coderez.

La section dont nous traitons concerne les Identifiants :naturel vs non naturel ; significatif vs sans signification. Plus tard, vous verrez comment nous pouvons utiliser la capacité relationnelle du moteur, lorsque la PK enfant est formée à partir de la PK parent. (Votre nom de famille n'est-il pas le même que celui de votre père ?)

Il est également important de comprendre les bases de données relationnelles et leur capacité. Cela est perdu lorsque nous abordons la base de données (par exemple) d'un point de vue OO et que nous la traitons comme un emplacement pour rendre nos classes "persistantes". Par conséquent, nous essaierons d'apprendre et d'utiliser des termes relationnels. Cela devient difficile lorsque vous allez en France et que vous vous attendez à ce qu'ils parlent américain et utilisent la même monnaie; apprenez à parler 10 mots de français, et ils vous accueillent à bras ouverts, et vous vivrez une expérience assez différente avec les locaux.

Quoi qu'il en soit, continuez à mettre en œuvre le modèle. Réalisez simplement que nous ferons probablement un changement à un moment donné. Enregistrez tous vos DDL. Enregistrez toutes vos données de test sous forme d'instructions d'insertion ou sous forme de sauvegarde de table ou d'exportation de format de caractères (aucune idée de ce que MySQL peut/ne peut pas faire dans ce domaine).
37.1. Géré, la relation n::n avec Office &Category . Vous ne "le verrez" que lorsque nous arriverons au modèle physique.

37.2. Terminé.

37.3 Terminé.
.
38. Excellent. Plus court aussi. Notez qu'ils ne pourront jamais avoir deux Offices dans le même code postal. NUMERIC (5,0) est bon, mais je pensais que les États-Unis se dirigeaient vers 7 chiffres. Peu importe, vous pouvez le comprendre; c'est un excellent PK pour Office . Maintenant cette colonne, qui faisait partie de Address , probablement ZipCode , a été élevé à un but supérieur, sans double emploi ; puisque nous le transportons dans 5 tables enfants, et que nous voulons que le nom PK soit clair, selon les conventions expliquées précédemment, nous l'appellerons OfficeCode; OfficeZipCode peut-être idiot.

Nous avons besoin d'un index unique sur Name pour s'assurer qu'ils n'ajoutent pas deux Offices avec le même nom. Remarque, à des fins d'explication, il s'agit en fait de la clé logique de Office , remplaçant (StateCode, Town) , et il en est ainsi.

Je pense toujours que vous pourriez avoir besoin de StateCode et Town comme référence rapide (autre que de s'asseoir quelque part dans Address )

Modèle de données mis à jour, cinquième maintenant disponible pour examen. Vous n'avez pas indiqué votre préférence, pour ...Date vs ...Dtm . Je vais avec ce dernier, car il est plus spécifique, identifiant également la composante temporelle. Facile à changer.

Cette réponse a atteint la longueur maximale. Suite dans la "Partie II"