Nástěnka - Optimalizace databáze

.
22.3. Potřeba pochopit proč, není vůbec žádný problém. Jen děti slepě dodržují jednoduchá pravidla a ty mezi ně určitě nepatříš.
.
23. Potvrzeno:users.total_bulletins je nadbytečný; lze to odvodit. Odebráno.
.
24. Všechny vaše PK jsou ID. Ještě vás nebaví se ztrácet v kódu? Zapomeňte na nalepení Id iot PKs na vše, co se hýbe, pojďme zjistit, jak vaši uživatelé Identifikujte jejich entity; které Entity jsou skutečně nezávislé a ty druhé, které závisí na Nezávislých entitách.

24.1. Nikdy nepoužívejte Id nebo v jakékoli takové formě. Pokud se jedná o PK, použijte úplný formulář.

24.2. Volejte location_id, location_id, ať je kdekoli, včetně tabulky PK. Výjimkou je situace, kdy potřebujete ukázat roli. To bude zřejmé v datovém modelu.
.
25. Nemáte žádnou deklarativní referenční integritu, žádnou definovanou Cizí klíče. To je špatná zpráva z mnoha různých důvodů. Jakmile budou tyto otázky vyjasněny, přidejte je prosím. DRI znamená, že v SQL je deklarována integrita co nejvíce, ne-li všechny. ISO/IEC/ANSI SQL standard to umožňuje, ale freewarový konec trhu standard neposkytuje a pomalu ho dohání. Znamená to, že server nepovolí přidání řádku do tabulky FK, pokud PK neexistuje v nadřazené tabulce. MySQL nedávno poskytlo DRI pro cizí klíče. Informace o FK najdete na ▶ tento článek◀ .

25.1. Pro CHECK omezení a PRAVIDLA je budete muset implementovat do kódu.

moje cizí klíče jsou podobné, users-id(fk) =users.id(pk) Nejsem si jistý, jak je přidat jiné než to, co jsem udělal, ale určitě to udělám, jakmile budu vědět, jak na to.

Dvacet pět. Poznamenané komentáře. Nejsem specialista na MySQL. Ano, to jsou problémy, na které musíte přijít sami. Obecně, z mého prohlížení, je MySQL beznohé; pro cokoliv SQL potřebujete InnoDB.

.
27. Vzhledem k tomu:Přehodnotil jsem požadavky na řazení bulletinu. Uživatelé mohou třídit chronologicky - snadné, dává to smysl. Uživatelé mohli bulletiny třídit podle data poslední odpovědi na bulletin. Pak můžeme zapomenout na pořadí a mělo by být opravdu snadné řadit bulletiny chronologicky podle času jejich poslední odpovědi? Jaké jsou vaše myšlenky.

Otevřené problémy

(Nic)

Datový model

Dobře, za předpokladu, že nemáte problémy s ERD, a implementací všech uzavřených problémů jsem namodeloval data a připravil Pátý datový model 9. prosince 10 k prohlédnutí. Rozhodně potřebuji mnohem více zpětnou vazbu, dotazy atd. k tomu. Mám potíže přijmout, že je to hotovo. Pravděpodobně nejlepší bude začít psát skutečný kód pro vaše problémové oblasti.

Odkazy

▶Odkaz na IDEF1X Notation◀ Toto si opravdu musíte přečíst a porozumět tomu, než si přečtete datový model.

▶Odkaz na data pátého bulletinu Model◀ Diagram vztahu entit je na první stránce, za ním následuje Datový model .

• Klíče jsou do značné míry rovné IDEF1X (kromě UserId, které jsem uvedl jako protipól); což znamená relační klíče peněženky. Nevylepšené a neoptimalizované pro fyzikální aspekty. Než se na ně vrhnete, nejprve si jich všimněte, registrujte je a vyhodnoťte. Samozřejmě můžeme přidat Id iot klíčů, ale než to uděláme, ujistěte se, že rozumíme tomu, co ztratíme.

• Všimněte si identifikátorů (plné čáry) podle dokumentu Notation. Páteř, obratle systému je Location ... Bulletin ... Response .

• Všimněte si, že Klíče ve skutečnosti implementují mnoho obchodních pravidel.

• Všimněte si přirozené hierarchie, kterou jsem vykreslil. Podívejte se, jestli to pro vás má nějaký význam.

• VerbPhrases jsou opravdu důležité; uvidíme, jestli něco znamenají.

Komentáře k prvnímu datovému modelu a odpovědi

Jeden dotaz, který mám, je, že primární klíč umístění bude použit k vytvoření podřízeného primárního klíče? (jsou spojeny plnou čarou) Moc tomu konceptu nerozumím

• Jaký je dobrý identifikátor pro Bulletin? , co vaši uživatelé přirozeně používají k identifikaci bulletinu ...
• "viděli jste včera bulletin z Virginie FO?",
• "Sally z Washingtonu určitě píše dobré bulletiny" atd.

nebo proč takový vztah mezi uživatelem a bulletinem neexistuje?

• Podle záměru uvedeného výše, protože jsem nyní ukázal hodnocení jako tabulku a jaké by bylo vykreslení, jednou to odstraním

• Myslím, že Permission by měla být entita.

• Bulletin PK je nyní (StateCode, Town, UserId, SequenceNo) . Aby bylo jasno, SequenceNo je v rámci StateCode, Town, UserId :bude to 5 pro Sallyin 5. bulletin o MO/Billngs FO.

• Všimněte si, že uživatelské nastavení BulletinsPerPage , atd., jsou 1::1 s User , takže jsou v User; podřízená tabulka by byla nesprávná.

• Opraveny typografické chyby.

Komentáře k druhému datovému modelu a odpovědi

• Soubory PK pro oba Bulletin a Response byly změněny tak, aby odrážely (7). BulletinNo a ResponseNo byly nahrazeny BulletinDate a ResponseDate (což bývalo CreatedDate ), aby bylo možné více odpovědí na User podle Bulletin .

Komentáře ke třetímu datovému modelu a odpovědi

Věřte, že jste měli dobrou přestávku.

1. Nejméně před 30 lety (což vím) měli giganti v tomto odvětví tuto debatu. Jména jsou vždy v jednotném čísle. Tabulky jsou podstatná jména. Slovesné fráze jsou slovesa. To se neomezuje na konvence pojmenování db, platí to pro dokumenty, diplomové práce, disertační práce atd. Na konci dokumentu můžete mít 5 závěrů, ale název sekce nebo kapitoly v ToC i v horní části stránky je "Závěr".

   Poté, co jsem s nimi bojoval celou cestu přes Uni, jakmile jsem nastoupil do své první placené programátorské práce a viděl důležitost pravidel v reálném světě, na rozdíl od teoretických argumentů, které jsme měli na vysoké škole, vzdal jsem to jako plýtvání. času. Veškerý ten čas a energie, které jsem promarnil, jsem uvolnil k produktivní práci. Od té doby nezpochybňuji obry; Jen přijímám. Že jejich mysl je větší než moje. Je to jako přijímat standardy nebo chovat se v rámci zákona nebo Boha. Nemám žádné opravdu, opravdu dobré důvody pro to, abych dělal něco nezákonného.

   Každopádně, snadnost jazykování (diskuze, SQL, dokumentace), kterou taková pravidla podporují, nelze dostatečně vysvětlit; jak budete psát další a další kód SQL, bude to jasné.

   Vždy můžete volně používat, co chcete. Dodávám pouze v jednotném čísle.

2. V pohodě u mě.

   Ale musíte mít na paměti, že tyto dva prvky v identifikované sekvenci (ala non-PK Unique Index nebo Alternate Key) jsou všeobecně vyžadovány pro stanovení jedinečnosti pro osobu. Jejich odstranění bude mít za následek dvě věci. Za prvé, již nebudete moci identifikovat jedinečnost mezi Users (a proto můžete mít duplicitní řádky). Za druhé, AK se stane nejedinečným, Inversion Entry.

3. Jde o to (na rozdíl od jednoho z příspěvků) jakýkoli sloupec, který je 1::1 s User PK, měl by být umístěn v User . Všechna nastavení předvoleb. Od té doby, co jsme vyčistili InterestedLocations a InterestedCategories , Vím pouze o BulletinsPerPage zbývající; ale jsem si jistý, že existují další. IsPreference2 je např. boolean;NumPreference3 je např. celého čísla. Atd. Můžete mi říct, jaké jsou skutečné preference.

   (Zkusme to v množném čísle:... libovolný sloupec, který je 1::1 s Users PK, měl by být umístěn v Users . Prostě to za mě nedělá, zavěšuji se na lámanou angličtinu a jsem trochu vzácnější ohledně svého mateřského jazyka.)

   Datový model aktualizován.

4. Vynikající. Dejte mi vědět, až vám to bude vyhovovat, a já vám dám fyzický model.

   A co VerbPhrases?

Komentáře k 6. prosinci 10 20:38 EST (malé aktualizace)

.
28. Tam, kde je pouze jeden výskyt PK jako FK, je samozřejmě název sloupce FK stejný jako název sloupce PK. Pokud je však FK více než jeden occ (podívejte se na ResponseRating ), existují tři UserIds ), musíme je rozlišovat. V terminologii IDEF1X se tomu říká role. Role User kdo vydal Bulletin je Issuer , a tak dále. Je zřejmé, že je lepší používat tento název a udržovat jej konzistentní v celé hierarchii (ne UserIds v Bulletin a poté, když se dostaneme k Response , kde jsou dva a je požadováno rozlišení, změňte jej na IssuerId . Myslel jsem, že s tím můžeš mít problém; v raných fázích se používá Issuer.UserId tak, aby bylo zcela jasné, že se jedná o UserIds jako FK a Role je Issuer; když se dostaneme k fyzickému modelu, zjednoduší se na IssuerId .

Podobně máme mnoho sloupců DateTime (pokud chcete zkráceně Date; jinak Dtm), které je třeba odlišit.
.
29. Nedával dokument IDEF1X Notation smysl?

• PK pro každou tabulku je nad čarou v určeném pořadí.
• Nezapomeňte, že stejně neseme PK nadřazených tabulek, a pokud to má smysl, použijeme tyto PK k vytvoření podřízené PK.

• Pro Bulletin :

  • Umístění FK (StateCode, Town) pro které je vydáno
  • UserIds emitenta
  • a DateTime it issued, aby to bylo jedinečné.
  • proto (StateCode, Town, IssuerId, BulletinDate)`

• Chcete-li odstranit všechna ResponseRatings pro tento Bulletin , použijte WHERE = na těchto čtyřech Bulletin sloupců.

.
30. Protože (State, Town) je kód PK Location , nosit kamkoli. A tvoří součást Bulletin PK, takže všechny závislé tabulky obsahují tyto sloupce, protože obsahují Bulletin PK.

Již dříve jsme identifikovali, že (State, Town) je PK, Nechám to tak, jak je Pro změnu viz (38).

.
33. Stojí za diskusi. Ano, pokud jej budete zobrazovat při (např.) zobrazování Responses a uživatelé rozumějí UserName . Ne, pokud je 30 bajtů a je tam také jedinečné 4 bajtové UserIds . Cílem je učinit tato rozhodnutí vědomě, vědomi si toho, čeho se vzdáváte, když nakonec usoudíte, že nějaký 6sloupcový 30bajtový klíč je příliš těžkopádný na to, aby se přesunul k dětem.

• Na začátku jsem uvedl, že bych použil UserIds jako typické Id Pk, protože je přenášen/migrován do několika podřízených tabulek.
• Způsob vytvoření si můžeme nechat na později. Ale je to čistý náhradní PK.

.
34. Žádný problém. Category už to má. Změním Order na ListOrder .

.
35. Tak určitě. Podle toho, co jsem četl a slyšel, jsem s ním docela spokojený. Ale chtěl bych více tam a zpět, abych dosáhl jisté sebedůvěry, než napíšete kód. Případně to považujte za vzdělávací zkušenost a přijměte, že model a kód se mohou později změnit. Chcete, abych teď vytvořil Fyzikální? Pokud mi poskytnete nějaké opravy, zveřejním další verzi. Očekávám předvolby v User . Rychle si také projděte funkce a zkontrolujte, zda máte všechny potřebné sloupce.

Podívejte se na některé další odpovědi za účelem učení a zájmu.

.
36. Připojí se. Stačí se připojit na čtyři tři sloupce na rozdíl od jednoho. SQL je při spojování těžkopádný a nová syntaxe, která to měla usnadnit, je ve skutečnosti těžkopádnější. Moji kodéři nikdy nepíší spojení:šetříme čas a překlepy. Mám proces, který vzhledem ke dvěma nebo více tabulkám vygeneruje kód se všemi sloupci a spojeními. Neznám dost MySQL, abych to pro vás převedl.

Datový model aktualizován.
.

Komentáře k 8. prosinci 10 20:49, Čtvrtý datový model a odpovědi

.
Zkontrolujte předchozí sekci bezprostředně výše, jsou tam malé aktualizace.

IDEF1X:Vaše rychlost je v pořádku.

Poznamenejte si dítě vždy "zdědí" nadřazený PK jako FK (buď plná nebo přerušovaná čára), jinak mezi nimi není žádný vztah. Použitím těchto sloupců, které stejně v podřízeném prvku existují, k vytvoření podřízeného PK, neseme význam (a to je rozdíl mezi pevným a zlomeným). Nemusíme tedy pro dítě hledat samostatný Identifikátor. Relační síla v této metodě bude jasná později, když budete kódovat.

Část, kterou se zabýváme, se týká Identifikátorů :přirozené vs nepřirozené; smysluplné vs nesmyslné. Později uvidíte, jak můžeme využít relační schopnost enginu, když je potomek PK tvořen z nadřazeného PK. (Není vaše příjmení stejné jako příjmení vašeho otce?)

Je také důležité porozumět relačním databázím a jejich schopnostem. To je ztraceno, když přistupujeme k databázi (např.) z perspektivy OO a zacházíme s ní jako s místem, aby naše třídy byly "trvalé". Proto se pokusíme naučit a používat Relační termíny. Je to těžké, když jedete do Francie a očekáváte, že tam budou mluvit americky a budou používat stejnou měnu; naučte se mluvit 10 slov francouzsky, přivítají vás s otevřenou náručí a s místními zažijete úplně jiný zážitek.

Každopádně pokračujte v implementaci modelu. Uvědomte si, že v určitém okamžiku pravděpodobně uděláme změnu. Uložte všechny své DDL. Uložte všechna svá testovací data jako příkazy vložení nebo jako zálohu tabulky nebo export formátu znaků (nemám ponětí, co MySQL v této oblasti umí/nemůže)..
37.1. Řeší se vztah n::n s Office &Category . To „uvidíte“, až se dostaneme k fyzickému modelu.

37.2. Hotovo.

37.3 Hotovo.
.
38. Vynikající. Stejně tak kratší. Všimněte si, že nikdy nebudou moci mít dvě Offices ve stejném PSČ. NUMERIC(5,0) je dobré, ale myslel jsem, že USA se pohybují směrem k 7 číslicím. Nevadí, můžete na to přijít; je to vynikající PK pro Office . Nyní tento sloupec, který byl součástí Address , pravděpodobně ZipCode , byla povýšena na vyšší účel, bez duplicit; protože jej neseme v 5 podřízených tabulkách a chceme, aby byl název PK jasný, podle dříve vysvětlených konvencí, budeme jej nazývat OfficeCode; OfficeZipCode může být hloupé.

Potřebujeme jedinečný index pro Name aby se zajistilo, že nepřidají dvě Offices se stejným jménem. Všimněte si, že pro účely vysvětlení je to ve skutečnosti logický klíč Office , nahrazující (StateCode, Town) a zůstane to tak.

Stále si myslím, že možná budete potřebovat StateCode a Town jako rychlý odkaz (jiný než sedět někde v Address )

Datový model aktualizován, pátý je nyní k dispozici ke kontrole. Neuvedli jste své preference pro ...Date vs ...Dtm . Jdu s tím druhým, protože je specifičtější a identifikuji také časovou složku. Snadná změna.

Tato odpověď dosáhla maximální délky. Pokračování v "části II"