Bulletin board - Database-optimalisatie

.
22.3. Behoefte om te begrijpen waarom, is helemaal geen probleem. Alleen kinderen volgen blindelings simpele regels, en jij bent daar zeker niet een van.
.
23. Bevestigd:users.total_bulletins is overbodig; het kan worden afgeleid. Verwijderd.
.
24. Al uw PK's zijn ID's. Ben je het nog niet zat om in de code te verdwalen? Vergeet het plakken van Id iot PK's op alles wat beweegt, laten we eens kijken hoe uw gebruikers Identificeer hun entiteiten; welke entiteiten werkelijk onafhankelijk zijn en de andere die afhankelijk zijn van onafhankelijke entiteiten.

24.1. Gebruik nooit Id of een dergelijke vorm. Als het een PK is, gebruik dan het volledige formulier.

24.2. Bel location_id, location_id, waar het ook is, inclusief de PK-tabel. De uitzondering is wanneer u de rol moet tonen. Dit wordt duidelijk in het Data Model.
.
25. Je hebt geen Declarative Referentiële Integriteit, geen Gedefinieerde Buitenlandse sleutels. Dat is om veel verschillende redenen slecht nieuws. Zodra deze vragen zijn opgehelderd, voeg ze dan toe. DRI betekent dat zoveel mogelijk, zo niet alle, integriteit wordt verklaard in SQL. De ISO/IEC/ANSI SQL-standaard maakt dit mogelijk, maar het freeware-uiteinde van de markt biedt niet de standaard en haalt langzaam zijn achterstand in. Dit betekent dat de server niet toestaat dat een rij in de FK-tabel wordt toegevoegd, tenzij de PK in de bovenliggende tabel bestaat. MySQL heeft onlangs DRI voor Foreign Keys geleverd. Raadpleeg voor FK's ▶ dit artikel◀ .

25.1. Voor CHECK-beperkingen en RULES moet u deze in code implementeren.

mijn externe sleutels zijn als, users-id(fk) =users.id(pk) Ik weet niet zeker hoe ik ze moet toevoegen, behalve wat ik heb gedaan, maar zal dat zeker doen zodra ik weet hoe.

Vijfentwintig. Opmerkingen genoteerd. Ik ben geen MySQL-specialist. Ja, dat zijn de dingen die je zelf moet uitzoeken. Over het algemeen is MySQL, als ik het doorlees, pootloos; voor alles wat SQL-achtig is, heb je InnoDB nodig.

.
27. Gegeven:Ik heb de sorteervereisten voor bulletin opnieuw bekeken. Gebruikers kunnen chronologisch sorteren - eenvoudig, logisch. Gebruikers konden bulletins sorteren op de datum van het laatste antwoord op het bulletin. Dan kunnen we de rangorde vergeten en zou het heel gemakkelijk moeten zijn om bulletins chronologisch te sorteren op de tijd van hun laatste reactie? Wat zijn je gedachten.

Openstaande problemen

(Nul)

Gegevensmodel

Oké, ervan uitgaande dat je geen problemen hebt met de ERD en alle gesloten problemen implementeert, heb ik de gegevens gemodelleerd en een Vijfde gegevensmodel 09 december 10 opgesteld voor uw recensie. Ik heb zeker veel meer nodig feedback, vragen, etc. hierover. Ik heb moeite om te accepteren dat het gedaan is. Waarschijnlijk het beste om echte code te schrijven voor uw probleemgebieden.

Links

▶Link naar IDEF1X-notatie◀ U moet dit echt lezen en begrijpen voordat u het gegevensmodel leest.

▶Link naar gegevens van het vijfde bulletin Model◀ Het Entiteitsrelatiediagram staat op de eerste pagina, gevolgd door het Gegevensmodel .

• De sleutels zijn vrijwel recht IDEF1X (behalve voor UserId die ik als contrapunt heb verstrekt); wat betekent portemonnee relationele sleutels. Niet verbeterd en niet geoptimaliseerd voor fysieke overwegingen. Merk ze eerst op, registreer ze en evalueer ze voordat je ze tegen je in het harnas jaagt. Natuurlijk kunnen we toevoegen Id iot-sleutels, maar voordat we dat doen, moeten we ervoor zorgen dat we begrijpen wat we gaan verliezen.

• Let op de ID's (ononderbroken lijnen) volgens het notatiedocument. De wervelkolom, de wervels van het systeem is Location ... Bulletin ... Response .

• Merk op dat Keys veel bedrijfsregels implementeert.

• Let op de natuurlijke hiërarchie die ik heb weergegeven. Kijk of het iets voor jou betekent.

• De werkwoordzinnen zijn erg belangrijk; kijk of ze iets betekenen.

Opmerkingen over het eerste gegevensmodel en reacties

Een vraag die ik heb is dat de primaire sleutel van de locatie zal worden gebruikt om de onderliggende primaire sleutel te vormen? (ze zijn verbonden door een ononderbroken lijn) Ik begrijp dat concept niet echt

• Wat is een goede identificatie voor Bulletin? , wat gebruiken uw gebruikers natuurlijk om een ​​bulletin te identificeren ...
• "heb je het bulletin van Virginia FO gisteren gezien?",
• "Sally uit Washington schrijft zeker goede bulletins", enz.

of waarom bestaat die relatie niet tussen de gebruiker en het bulletin?

• Zoals hierboven vermeld, zal ik, aangezien ik Rating nu als een tabel heb getoond en wat de weergave zou zijn, een keer verwijderen

• Ik denk dat Toestemming een Entiteit zou moeten zijn.

• Bulletin PK is nu (StateCode, Town, UserId, SequenceNo) . Voor alle duidelijkheid:SequenceNo is binnen StateCode, Town, UserId :het wordt 5 voor Sally's 5e bulletin over MO/Billngs FO.

• Merk op dat gebruikersinstellingen BulletinsPerPage ,etc, zijn 1::1 met User , dus ze staan ​​in User; kindertabel zou onjuist zijn.

• Typografische fouten gecorrigeerd.

Opmerkingen bij tweede gegevensmodel en antwoorden

• De PK's voor beide Bulletin en Response zijn gewijzigd om weer te geven (7). BulletinNo en ResponseNo zijn vervangen door BulletinDate en ResponseDate (dat was CreatedDate ), om meerdere antwoorden toe te staan ​​per User per Bulletin .

Opmerkingen over het derde gegevensmodel en antwoorden

Vertrouw erop dat je een goede vakantie hebt gehad.

1. Minstens 30 jaar geleden (voor zover ik weet) hadden de reuzen in de industrie dit debat. Namen zijn altijd enkelvoud. Tabellen zijn zelfstandige naamwoorden. WerkwoordZinnen zijn werkwoorden. Dit is niet beperkt tot db-naamgevingsconventies, het is van toepassing op documenten, scripties, proefschriften, enz. U kunt 5 conclusies aan het einde van het document hebben, maar de titel van de sectie of het hoofdstuk, zowel in de inhoudsopgave als bovenaan de pagina is "Conclusie".

   Nadat ik ze helemaal door Uni had gevochten, zodra ik aan mijn eerste betaalde programmeerbaan begon en het belang van de regels in de echte wereld zag, in tegenstelling tot de theoretische argumenten die we op de universiteit hadden, gaf ik het op als een verspilling van tijd. Al die tijd en energie die ik verspilde, kwam vrij om productief werk te doen. Sindsdien twijfel ik niet meer aan de reuzen; Ik accepteer het gewoon. Dat hun geest groter is dan de mijne. Het is als het accepteren van Normen, of je gedragen binnen de wet, of God. Ik heb geen echt, hele goede redenen om iets illegaals te doen.

   Hoe dan ook, het gemak van taalgebruik (discussie, SQL, documentatie) dat door dergelijke regels wordt ondersteund, kan niet adequaat worden uitgelegd; naarmate je meer en meer SQL-code schrijft, wordt het duidelijk.

   Je bent altijd vrij om te gebruiken wat je wilt. Ik lever alleen enkelvoud.

2. Prima met mij.

   Maar u moet er rekening mee houden dat die twee elementen, in de geïdentificeerde volgorde (ofschoon niet-PK Unieke Index of Alternatieve Sleutel) universeel vereist zijn om Uniciteit voor een Persoon vast te stellen. Als u ze verwijdert, resulteert dit in twee dingen. Ten eerste kunt u de uniciteit van Users niet langer identificeren (en dus kunt u dubbele rijen hebben). Ten tweede wordt de AK niet-uniek, een Inversion Entry.

3. Het punt is (in tegenstelling tot een van de berichten), elke kolom die 1::1 is met deUser PK, moet zich bevinden inUser . Alle voorkeursinstellingen. Sinds we deInterestedLocations . hebben opgeruimd enInterestedCategories , ik ken alleen BulletinsPerPage overig; maar ik weet zeker dat er anderen zijn. IsPreference2 is een bijv. van een boolean;NumPreference3 is een bijv. van een geheel getal. Enz. Je kunt me vertellen wat de echte voorkeuren zijn.

   (Laten we dat eens in het meervoud proberen:... elke kolom die 1::1 is met deUsers PK, moet zich bevinden inUsers . Doet het gewoon niet voor mij, ik blijf hangen in het gebroken Engels, en ik ben een beetje kostbaar over mijn moedertaal.)

   Gegevensmodel bijgewerkt.

4. Uitmuntend. Laat me weten wanneer je je daar prettig bij voelt, en ik zal je het fysieke model geven.

   Hoe zit het met de werkwoordzinnen?

Reacties over 06 Dec 10 20:38 EST (Kleine Updates)

.
28. Waar PK slechts één keer voorkomt als een FK, is de FK-kolomnaam natuurlijk hetzelfde als de PK-kolomnaam. Wanneer er echter meer dan één occ van de FK is (kijk op ResponseRating ), zijn er drie UserIds ), moeten we ze onderscheiden. In IDEF1X-terminologie wordt dit Rollen genoemd. De rol van de User die het Bulletin heeft uitgegeven is Issuer , enzovoort. Het is duidelijk beter om die naam te gebruiken en consistent te houden in de hele hiërarchie (niet UserId in Bulletin en dan wanneer we bij Response . komen , waar er twee zijn en differentiatie vereist is, wijzigt u dit in IssuerId . Ik dacht dat je daar misschien een probleem mee zou hebben; in de vroege stadia is het gebruik Issuer.UserId zodat het absoluut duidelijk is dat het UserId . is als een FK, en de rol is Issuer; wanneer we bij het fysieke model komen, wordt het vereenvoudigd tot IssuerId .

Evenzo hebben we veel DateTime-kolommen (afgekort Date als je wilt; anders Dtm), die moeten worden onderscheiden.
.
29. Klopte het IDEF1X Notation-document niet?

• De PK voor elke tafel staat boven de lijn, in de opgegeven volgorde.
• Vergeet niet dat we de PK's van de bovenliggende tabellen hoe dan ook dragen, en als er betekenis is, die FK's gebruiken om de onderliggende PK te vormen.

• Voor Bulletin :

  • De locatie FK (StateCode, Town) waarvoor het is uitgegeven
  • De UserId van de Emittent
  • en DateTime het is uitgegeven, om het uniek te maken.
  • daarom (StateCode, Town, IssuerId, BulletinDate)`

• Om alle ResponseRatings te verwijderen voor dit Bulletin , gebruik WHERE = op die vier Bulletin kolommen.

.
30. Omdat (State, Town) is de PK van Location , overal mee naartoe nemen. En het maakt deel uit van het Bulletin PK, dus alle afhankelijke tabellen dragen die kolommen omdat ze het Bulletin . dragen PK.

We hadden eerder vastgesteld dat (State, Town) is de PK, Ik laat dat zoals het is Raadpleeg (38) voor wijzigingen.

.
33. Discussie waard. Ja, als u het gaat weergeven bij (bijv.) het weergeven van Responses , en de gebruikers begrijpen UserName . Nee, als het 30 bytes is, en er is ook een unieke 4 byte UserId . Het idee is om deze keuzes bewust te maken, bewust van wat je opgeeft, wanneer je uiteindelijk besluit dat een 6-koloms 30-byte sleutel te omslachtig is om naar de kinderen te migreren.

• Ik heb in het begin aangegeven dat ik UserId . zou gebruiken als een typische Id Pk, omdat het wordt gedragen/gemigreerd naar verschillende onderliggende tabellen.
• We kunnen laten hoe dat is gemaakt voor later. Maar het is een pure Surrogaat PK.

.
34. Geen probleem. Category heeft het al. Ik verander Order naar ListOrder .

.
35. Zeker. Op basis van wat ik heb gelezen en gehoord, ben ik er best blij mee. Maar ik zou graag wat meer heen en weer willen om wat vertrouwen te krijgen, voordat je code schrijft. Of bekijk het als een leerervaring en accepteer dat het model en de code later kunnen veranderen. Wil je dat ik de Physical nu produceer? Als u mij alle correcties geeft, zal ik de volgende versie publiceren. Ik verwacht voorkeuren in User . Loop ook snel door de functies en controleer of je alle kolommen hebt die je nodig hebt.

Kijk naar enkele van de andere antwoorden, met het oog op leren en interesse.

.
36. Doet mee. Je doet gewoon mee op four drie kolommen in plaats van één. SQL is omslachtig met joins, en de nieuwe syntaxis die het gemakkelijker moest maken, is eigenlijk omslachtiger. Mijn programmeurs schrijven nooit joins:we besparen tijd en typefouten. Ik heb een proc die twee of meer tabellen geeft, de code genereert met alle kolommen en joins. Ik weet niet genoeg van MySQL om dat voor je om te zetten.

Gegevensmodel bijgewerkt.
.

Opmerkingen over 10 december 20:49, vierde gegevensmodel en antwoorden

.
Controleer de vorige sectie direct hierboven, er zijn kleine updates.

IDEF1X:Je snelheid is prima.

Let op het kind altijd "erft" de ouder-PK, als een FK (ofwel ononderbroken of onderbroken lijn), anders is er geen relatie tussen hen. Door deze kolommen, die toch al in het kind aanwezig zijn, te gebruiken om de PK van het kind te vormen, dragen we de betekenis (en dat is het verschil tussen vast en kapot). En dus hoeven we niet te zoeken naar een onafhankelijke Identifier voor het kind. De relationele kracht in deze methode zal later duidelijk worden, wanneer je aan het coderen bent.

Het gedeelte waar we mee te maken hebben, gaat over Identifiers :natuurlijk versus onnatuurlijk; zinvol vs zinloos. Later zul je zien hoe we het relationele vermogen van de motor kunnen gebruiken, wanneer het kind-PK wordt gevormd uit het ouder-PK. (Is je achternaam niet hetzelfde als die van je vader?)

Het is ook belangrijk om relationele databases en hun mogelijkheden te begrijpen. Dat gaat verloren wanneer we de database (bijv.) benaderen vanuit een OO-perspectief, en het behandelen als een locatie om onze klassen "persistent" te maken. Daarom zullen we proberen relationele termen te leren en te gebruiken. Het wordt moeilijk als je naar Frankrijk gaat en verwacht dat ze Amerikaans spreken en dezelfde valuta gebruiken; leer 10 woorden Frans spreken, en ze verwelkomen je met open armen, en je zult een heel andere ervaring hebben met de lokale bevolking.

Ga in ieder geval door met het implementeren van het model. Realiseer je dat we op een gegeven moment waarschijnlijk een verandering zullen doorvoeren. Sla al uw DDL op. Sla al uw testgegevens op als invoeginstructies of als tabelback-up of export van tekenformaat (geen idee wat MySQL op dit gebied wel/niet kan doen).
37.1. Behandeld, de n::n relatie met Office &Category . Dat zul je pas "zien" als we bij het fysieke model komen.

37.2. Klaar.

37.3 Klaar.
.
38. Uitmuntend. Korter ook. Merk op dat ze nooit twee Offices kunnen hebben in dezelfde postcode. NUMERIC(5,0) is goed, maar ik dacht dat de VS op weg was naar 7 cijfers. Maakt niet uit, je kunt het uitzoeken; het is een uitstekende PK voor Office . Nu deze kolom, die deel uitmaakte van Address , waarschijnlijk ZipCode , is verheven tot een hoger doel, zonder duplicatie; aangezien we het in 5 onderliggende tabellen hebben en we willen dat de PK-naam duidelijk is, zoals eerder uitgelegd in de conventies, zullen we het OfficeCode noemen; OfficeZipCode is misschien dom.

We hebben een unieke index nodig op Name om ervoor te zorgen dat ze niet twee Offices . toevoegen met dezelfde naam. Let op, voor uitlegdoeleinden is dit eigenlijk de logische sleutel van Office , ter vervanging van (StateCode, Town) , en dat blijft zo.

Ik denk nog steeds dat je StateCode nodig hebt en Town als snelle referentie (anders dan ergens in Address te zitten) )

Gegevensmodel bijgewerkt, vijfde nu beschikbaar voor beoordeling. U heeft uw voorkeur niet aangegeven, voor ...Date vs ...Dtm . Ik ga met het laatste mee, omdat het meer specifiek is, en ook de tijdcomponent identificeert. Makkelijk te veranderen.

Dit antwoord heeft de maximale lengte bereikt. Vervolg in "Deel II"