Opslagstavle - Databaseoptimering

.
22.3. At skulle forstå hvorfor er ikke noget problem overhovedet. Kun børn følger blindt simple regler, og du er bestemt ikke en af ​​dem.
.
23. Bekræftet:users.total_bulletins er overflødig; det kan udledes. Fjernet.
.
24. Alle dine PK'er er id'er. Er du ikke blevet træt af at fare vild i koden endnu? Glem alt om at sætte Id fast iot PK'er på alt, der bevæger sig, lad os finde ud af, hvordan dine brugere Identificere deres enheder; hvilke enheder er virkelig uafhængige, og de andre, der afhænger af uafhængige enheder.

24.1. Brug aldrig Id eller enhver sådan form. Hvis det er en PK, skal du bruge den fulde formular.

24.2. Kald location_id, location_id, uanset hvor det er, inklusive PK-tabellen. Undtagelsen er, når du skal vise rollen. Dette vil blive tydeligt i datamodellen.
.
25. Du har ingen deklarativ referenceintegritet, ingen defineret Fremmednøgler. Det er dårlige nyheder af mange forskellige årsager. Når disse spørgsmål er afklaret, bedes du tilføje dem. DRI betyder, at så meget som muligt, hvis ikke alle, integritet er erklæret i SQL. ISO/IEC/ANSI SQL-standarden tillader dette, men freeware-enden af ​​markedet leverer ikke standarden og er langsomt ved at indhente det. Det betyder, at serveren ikke tillader, at en række i FK-tabellen tilføjes, medmindre PK'en findes i den overordnede tabel. MySQL leverede for nylig DRI til fremmednøgler. For FK'er, se ▶ denne artikel◀ .

25.1. For CHECK-begrænsninger og REGLER skal du implementere dem i kode.

mine fremmednøgler er som, users-id(fk) =users.id(pk) Jeg er ikke sikker på, hvordan jeg tilføjer dem andet end det, jeg har gjort, men vil helt sikkert gøre det, når jeg ved, hvordan.

Femogtyve. Kommentarer noteret. Jeg er ikke en MySQL-specialist. Ja, det er de problemer, du selv skal finde ud af. Generelt set fra min gennemlæsning er MySQL benløs; til noget SQL-agtigt har du brug for InnoDB.

.
27. Givet:Jeg har genovervejet sorteringskravene til bulletin. Brugere kunne sortere kronologisk - nemt, giver mening. Brugere kunne sortere bulletiner efter datoen for det seneste svar på bulletinen. Så kan vi glemme rang, og det burde være virkelig nemt at sortere bulletiner kronologisk efter tidspunktet for deres sidste svar? Hvad er dine tanker.

Åbne numre

(Nul)

Datamodel

Ok, forudsat at du ikke har problemer med ERD og implementerer alle lukkede problemer, har jeg modelleret dataene og udarbejdet en femte datamodel 09. december 10 til dit gennemsyn. Jeg har bestemt brug for meget mere feedback, spørgsmål osv. herom. Jeg har svært ved at acceptere, at det er gjort. Det er nok bedst at begynde at skrive rigtig kode til dine problemområder.

Links

▶Link til IDEF1X-notation◀ Du skal virkelig læse og forstå dette, før du læser Datamodellen.

▶Link til Fifth Bulletin Data Model◀ Entity Relation Diagram er på den første side, efterfulgt af datamodellen .

• Nøglerne er stort set lige IDEF1X (bortset fra UserId, som jeg angav som et modspil); hvilket betyder pung Relationelle nøgler. Uforbedret og ikke optimeret til fysiske overvejelser. Før du bulker på dem, skal du først lægge mærke til dem, registrere dem og evaluere dem. Selvfølgelig kan vi tilføje Id iot-nøgler, men før vi gør det, så lad os sikre os, at vi forstår, hvad vi kommer til at miste.

• Læg mærke til identifikatorerne (optrukne linjer) i henhold til notationsdokumentet. Rygsøjlen, systemets ryghvirvler er Location ... Bulletin ... Response .

• Bemærk, at Keys faktisk implementerer mange forretningsregler.

• Læg mærke til det naturlige hierarki, som jeg har gengivet. Se om der er nogen mening i det for dig.

• Verbsætningerne er virkelig vigtige; se om de betyder noget.

Kommentarer til First Data Model og svar

Et spørgsmål, jeg har, er, at den primære nøgle for placeringen vil blive brugt til at danne den underordnede primære nøgle? (de er forbundet med en ubrudt linje) Jeg forstår ikke rigtig det koncept

• Hvad er en god identifikator for Bulletin? , hvad bruger dine brugere naturligt til at identificere en bulletin ...
• "har du set bulletinen fra Virginia FO i går?",
• "Sally fra Washington skriver helt sikkert gode bulletiner", osv.

eller hvorfor dette forhold ikke eksisterer mellem brugeren og bulletinen?

• I henhold til hensigten angivet yderligere ovenfor, da jeg nu har vist Rating som en tabel, og hvad gengivelsen ville være, fjerner jeg den én gang

• Jeg synes, at Tilladelse skal være en enhed.

• Bulletin PK er nu (StateCode, Town, UserId, SequenceNo) . For at være tydelig, SequenceNo er inden for StateCode, Town, UserId :det bliver 5 for Sallys 5. bulletin om MO/Billngs FO.

• Bemærk, at brugerindstillinger BulletinsPerPage ,etc, er 1::1 med User , så de er i User; underordnet tabel ville være forkert.

• Typografiske fejl rettet.

Kommentarer til anden datamodel og svar

• PK'erne for begge Bulletin og Responses er blevet ændret til at afspejle (7). BulletinNo og ResponseNo er blevet erstattet med BulletinDate og ResponseDate (som plejede at være CreatedDate ), for at tillade flere svar pr. User ifølge Bulletin .

Kommentarer vedrørende tredje datamodel og svar

Stol på, at du havde en god pause.

1. For mindst 30 år siden (det er jeg bekendt med) havde giganterne i branchen denne debat. Navne er altid ental. Tabeller er navneord. Verbsætninger er verber. Dette er ikke begrænset til db navngivningskonventioner, det gælder for dokumenter, afhandlinger, afhandlinger osv. Du kan have 5 konklusioner i slutningen af ​​dokumentet, men afsnittet eller kapitlets titel i både indholdsfortegnelsen og toppen af ​​siden er "Konklusion".

   Efter at have kæmpet mod dem hele vejen gennem Uni, så snart jeg startede mit første betalte programmeringsjob, og så vigtigheden af ​​reglerne i den virkelige verden, i modsætning til de teoretiske argumenter, vi havde på college, opgav jeg det som spild af tid. Al den tid og energi, jeg spildte, blev frigivet til at udføre produktivt arbejde. Siden da stiller jeg ikke spørgsmålstegn ved giganterne; Jeg accepterer bare. At deres sind er større end mit. Det er som at acceptere standarder eller opføre sig inden for loven eller Gud. Jeg har ingen rigtig, rigtig gode grunde til at gøre noget ulovligt.

   Under alle omstændigheder kan den lette sprogbrug (diskussion, SQL, dokumentation), der understøttes af sådanne regler, ikke forklares tilstrækkeligt; efterhånden som du skriver mere og mere SQL-kode, vil det blive tydeligt.

   Du er altid fri til at bruge, hvad du vil. Jeg leverer kun ental.

2. Fint med mig.

   Men du skal huske på, at disse to elementer i den identificerede rækkefølge (ala ikke-PK Unique Index eller Alternativ Key) er universelt nødvendige for at etablere Uniqueness for en Person. Fjernelse af dem vil resultere i to ting. For det første vil du ikke længere være i stand til at identificere unikhed på tværs af Users (og dermed kan du have duplikerede rækker). For det andet bliver AK'en ikke-unik, en Inversion Entry.

3. Pointen er (i modsætning til et af indlæggene), enhver kolonne, der er 1::1 med User PK, bør ligge iUser . Alle præferenceindstillinger. Siden vi har ryddet op i InterestedLocations og InterestedCategories , jeg kender kun til BulletinsPerPage resterende; men jeg er sikker på, at der er andre. IsPreference2 er en f.eks. af en boolesk;NumPreference3 er en f.eks. af et heltal. Osv. Du kan fortælle mig, hvad de rigtige præferencer er.

   (Lad os prøve det i flertal:... enhver kolonne, der er 1::1 med Users PK, bør ligge iUsers . Det gør det bare ikke for mig, jeg bliver hængt op i det ødelagte engelsk, og jeg er lidt dyrebar med mit modersmål.)

   Datamodel opdateret.

4. Fremragende. Lad mig vide, når du er tryg ved det, og jeg vil give dig den fysiske model.

   Hvad med verbsætningerne?

Kommentarer om 06. december 10 20:38 EST (Små opdateringer)

.
28. Hvor der kun er én forekomst af PK som FK, er FK kolonnenavnet selvfølgelig det samme som PK kolonnenavn. Men når der er mere end én occ af FK'en (tag et kig på ResponseRating ), er der tre UserIds ), er vi nødt til at differentiere dem. I IDEF1X terminologi kaldes dette roller. Users rolle der har udstedt Bulletin er Issuer , og så videre. Det er klart, at det er bedre at bruge dette navn og holde det konsistent i hele hierarkiet (ikke UserId i Bulletin og så når vi kommer til Response , hvor der er to, og der kræves en differentiering, skal du ændre den til IssuerId . Jeg tænkte, at du måske havde et problem med det; i de tidlige stadier er brugen Issuer.UserId så det er helt klart, at det er UserId som en FK, og rollen er Issuer; når vi kommer til den fysiske model, bliver den forenklet til IssuerId .

Ligeledes har vi mange DateTime-kolonner (dato for kort hvis du vil; ellers Dtm), der skal differentieres.
.
29. Gav IDEF1X-notationsdokumentet ikke mening?

• PK for hver tabel er over linjen i den angivne rækkefølge.
• Husk, at vi alligevel bærer PK'erne fra de overordnede tabeller, og hvis der er mening, skal du bruge disse FK'er til at danne den underordnede PK.

• Til Bulletin :

  • Placeringen FK (StateCode, Town) som den er udstedt for
  • UserId af Udsteder
  • og DateTime det blev udstedt, for at gøre det unikt.
  • derfor (StateCode, Town, IssuerId, BulletinDate)`

• For at slette alle ResponseRatings for denne Bulletin , brug WHERE = på de fire Bulletin kolonner.

.
30. Fordi (State, Town) er PK for Location , bærer overalt. Og det er en del af Bulletin PK, så alle afhængige tabeller bærer disse kolonner, fordi de bærer Bulletin PK.

Vi havde tidligere identificeret den (State, Town) er PK, Jeg vil lade det være som det er Se (38) for ændring.

.
33. Værd at diskutere. Ja, hvis du vil vise det, når du (f.eks.) viser Responses , og brugerne forstår UserName . Nej, hvis det er 30 bytes, og der også er et unikt 4 byte UserId . Ideen er at træffe disse valg bevidst, bevidst om, hvad du giver op, når du til sidst beslutter dig for, at en 6-søjle 30-byte nøgle er for besværlig til at migrere til børnene.

• Jeg sagde i starten, at jeg ville bruge UserId som et typisk Id Pk, fordi den føres/migreres til flere underordnede borde.
• Vi kan lade, hvordan det er oprettet, til senere. Men det er en ren surrogat-PK.

.
34. Intet problem. Category har det allerede. Jeg ændrer Order til ListOrder .

.
35. Jo da. Ud fra hvad jeg har læst og hørt, er jeg ret glad for den. Men jeg vil gerne have mere frem og tilbage for at opnå noget selvtillid, før du skriver kode. Alternativt kan du se det som en lærerig oplevelse og acceptere, at modellen og koden kan ændre sig senere. Vil du have mig til at producere den fysiske nu? Hvis du giver mig alle rettelser, udgiver jeg den næste version. Jeg forventer præferencer i User . Kør også hurtigt gennem funktionerne og kontroller, at du har alle de kolonner, du har brug for.

Se på nogle af de andre svar med henblik på læring og interesse.

.
36. slutter sig til. Du deltager bare på four tre kolonner i modsætning til én. SQL er besværligt med joins, og den nye syntaks, som skulle gøre det nemmere, er faktisk mere besværligt. Mine kodere skriver aldrig joins:vi sparer tid og tastefejl. Jeg har en proc, der givet to eller flere tabeller, vil generere koden med alle kolonner og joins. Jeg kender ikke nok til MySQL til at konvertere det for dig.

Datamodel opdateret.
.

Kommentarer ad 8. december 10 20:49, fjerde datamodel og svar

.
Tjek det forrige afsnit umiddelbart ovenfor, der er små opdateringer.

IDEF1X:Din hastighed er fin.

Bemærk barnet altid "arver" den overordnede PK, som en FK (enten fast eller brudt linje), ellers er der ingen relation mellem dem. Ved at bruge disse kolonner, der alligevel findes i barnet, til at danne underordnet PK, bærer vi betydningen (og det er forskellen mellem solid og ødelagt). Og dermed behøver vi ikke lede efter en selvstændig Identifier for barnet. Den relationelle kraft i denne metode vil blive tydelig senere, når du koder.

Det afsnit, vi har at gøre med, handler om Identifiers :naturlig vs unaturlig; meningsfuld vs meningsløs. Senere vil du se, hvordan vi kan bruge motorens Relationelle kapacitet, når den underordnede PK er dannet fra den overordnede PK. (Er dit efternavn ikke det samme som din fars?)

Det er også vigtigt at forstå relationelle databaser og deres muligheder. Det går tabt, når vi nærmer os databasen (f.eks.) fra et OO-perspektiv og behandler den som et sted for at gøre vores klasser "vedvarende". Derfor vil vi forsøge at lære og bruge Relationelle termer. Det bliver svært, når man tager til Frankrig og forventer, at de taler amerikansk, og bruger samme valuta; lær at tale 10 ord fransk, og de tager imod dig med åbne arme, og du får en helt anderledes oplevelse med de lokale.

Under alle omstændigheder, gå videre med at implementere modellen. Bare indse, at vi sandsynligvis vil lave en ændring på et tidspunkt. Gem alle dine DDL. Gem alle dine testdata som insert-sætninger eller som en tabelbackup eller karakterformateksport (ingen anelse om, hvad MySQL kan/ikke kan gøre i dette område).
37.1. Håndteres, n::n Relation til Office &Category . Det vil du først "se", når vi kommer til den fysiske model.

37,2. Færdig.

37.3 Udført.
.
38. Fremragende. Også kortere. Bemærk, at de aldrig vil kunne have to Offices i samme postnummer. NUMERISK(5,0) er godt, men jeg troede, at USA bevægede sig mod 7 cifre. Det gør ikke noget, du kan finde ud af det; det er en fremragende PK til Office . Nu denne kolonne, som var en del af Address , sandsynligvis ZipCode , er blevet ophøjet til et højere formål uden dobbeltarbejde; da vi bærer det i 5 underordnede tabeller, og vi ønsker, at PK-navnet skal være klart, vil vi ifølge tidligere forklarede konventioner kalde det OfficeCode; OfficeZipCode kan være dumt.

Vi har brug for et unikt indeks på Name for at sikre, at de ikke tilføjer to Offices med samme navn. Bemærk, til forklaringsformål er dette faktisk den logiske nøgle til Office , erstatter (StateCode, Town) , og det forbliver sådan.

Jeg tror stadig, at du muligvis har brug for StateCode og Town som en hurtig reference (bortset fra at sidde et sted i Address). )

Datamodel opdateret, femte nu tilgængelig til gennemgang. Du har ikke angivet din præference for ...Date vs ...Dtm . Jeg går med sidstnævnte, da det er mere specifikt, og identificerer også tidskomponenten. Let at ændre.

Dette svar har nået den maksimale længde. Fortsat i "Del II"