Tablica ogłoszeń - Optymalizacja bazy danych

.
22.3. Konieczność zrozumienia dlaczego nie stanowi żadnego problemu. Tylko dzieci ślepo przestrzegają prostych zasad, a Ty na pewno nie jesteś jednym z nich.
.
23. Potwierdzone:users.total_bulletins jest zbędny; można go wyprowadzić. Usunięto.
.
24. Wszystkie twoje PK to identyfikatory. Nie zmęczyłeś się jeszcze gubieniem się w kodzie? Zapomnij o wklejaniu Id iot PK na temat wszystkiego, co się rusza, dowiedzmy się, jak Twoi użytkownicy Zidentyfikuj ich podmioty; które Podmioty są naprawdę Niezależne, a inne, które zależą od Podmiotów Niezależnych.

24.1. Nigdy nie używaj Id lub w dowolnej takiej formie. Jeśli jest to PK, użyj pełnego formularza.

24.2. Wywołaj location_id, location_id, gdziekolwiek to jest, łącznie z tabelą PK. Wyjątkiem jest sytuacja, gdy musisz pokazać rolę. Stanie się to jasne w modelu danych.
.
25. Nie masz deklaratywnej integralności odniesienia, nie masz zdefiniowanej Klucz obcy. To zła wiadomość z wielu różnych powodów. Po wyjaśnieniu tych pytań dodaj je. DRI oznacza, że ​​w języku SQL zadeklarowana jest jak najwięcej, jeśli nie całość, integralności. Norma ISO/IEC/ANSI SQL pozwala na to, ale freeware koniec rynku nie zapewnia standardu i powoli nadrabia zaległości. Oznacza to, że serwer nie pozwoli na dodanie wiersza w tabeli FK, chyba że PK istnieje w tabeli nadrzędnej. MySQL dostarczył ostatnio DRI dla kluczy obcych. W przypadku FK patrz ▶ ten artykuł◀ .

25.1. W przypadku ograniczeń CHECK i REGUŁ, będziesz musiał zaimplementować je w kodzie.

moje klucze obce to:users-id(fk) =users.id(pk) Nie jestem pewien, jak je dodać poza tym, co zrobiłem, ale na pewno to zrobię, gdy będę wiedział, jak to zrobić.

Dwadzieścia pięć. Zanotowano komentarze. Nie jestem specjalistą MySQL. Tak, to są problemy, które musisz sam rozwiązać. Ogólnie rzecz biorąc, z mojego przeglądu MySQL jest beznogi; do wszystkiego, co związane z SQL, potrzebujesz InnoDB.

.
27. Biorąc pod uwagę:Przemyślałem ponownie wymagania dotyczące sortowania biuletynu. Użytkownicy mogliby sortować chronologicznie – łatwo, ma to sens. Użytkownicy mogli sortować biuletyny według daty ostatniej odpowiedzi na biuletyn. Wtedy możemy zapomnieć o randze i powinno być naprawdę łatwo posortować biuletyny chronologicznie według czasu ich ostatniej odpowiedzi? Jakie są Twoje przemyślenia.

Otwarte problemy

(brak)

Model danych

Ok, zakładając, że nie masz problemów z ERD i wdrażając wszystkie zamknięte problemy, wymodelowałem dane i przygotowałem Piąty model danych 9 grudnia 10 Do Twojego wglądu. Zdecydowanie potrzebuję dużo więcej informacje zwrotne, pytania itp. na ten temat. Mam trudności z zaakceptowaniem, że tak się stało. Prawdopodobnie najlepiej zacząć pisać prawdziwy kod dla obszarów problemowych.

Linki

▶Link do IDEF1X Notation◀ Naprawdę musisz to przeczytać i zrozumieć, zanim przeczytasz model danych.

▶Link do danych piątego biuletynu Model◀ Diagram relacji między jednostkami znajduje się na pierwszej stronie, a następnie Model danych .

• Klucze są prawie proste IDEF1X (z wyjątkiem UserId, który podałem jako kontrapunkt); co oznacza torebkę Klucze Relacyjne. Nieulepszony i niezoptymalizowany pod kątem fizycznym. Zanim zaczniesz się na nie czepiać, najpierw je zauważ, zarejestruj i oceń. Oczywiście możemy dodać Id klucze iot, ale zanim to zrobimy, upewnijmy się, że rozumiemy, co stracimy.

• Zwróć uwagę na Identyfikatory (linie ciągłe) zgodnie z dokumentem Notation. Kręgosłup, kręgi systemu to Location ... Bulletin ... Response .

• Zauważ, że klucze faktycznie implementują wiele reguł biznesowych.

• Zwróć uwagę na naturalną hierarchię, którą przedstawiłem. Zobacz, czy ma to dla Ciebie jakiekolwiek znaczenie.

• Frazy czasownikowe są naprawdę ważne; sprawdź, czy coś znaczą.

Komentarze dotyczące pierwszego modelu danych i odpowiedzi

Mam jedno pytanie, czy klucz podstawowy lokalizacji zostanie użyty do utworzenia podrzędnego klucza podstawowego? (są one połączone linią ciągłą) Naprawdę nie rozumiem tego pojęcia

• Co to jest dobry identyfikator biuletynu? , czego twoi użytkownicy naturalnie używają do identyfikacji biuletynu...
• „czy widziałeś wczoraj biuletyn z Wirginii FO?”,
• „Sally z Waszyngtonu pisze dobre biuletyny” itp.

lub dlaczego ta relacja nie istnieje między użytkownikiem a biuletynem?

• Zgodnie z intencją opisaną powyżej, ponieważ teraz pokazałem ocenę jako tabelę i jakie będzie renderowanie, raz ją usunę

• Myślę, że Pozwolenie powinno być Jednostką.

• Bulletin PK to teraz (StateCode, Town, UserId, SequenceNo) . Aby było jasne, SequenceNo znajduje się w StateCode, Town, UserId :będzie 5 w piątym biuletynie Sally w sprawie MO/Billngs FO.

• Pamiętaj, że ustawienia użytkownika BulletinsPerPage itd. są 1::1 z User , więc znajdują się w User; tabela podrzędna byłaby nieprawidłowa.

• Poprawiono błędy typograficzne.

Komentarze dotyczące drugiego modelu danych i odpowiedzi

• PK do obu Bulletin i Response zostały zmienione w celu odzwierciedlenia (7). BulletinNo i ResponseNo zostały zastąpione przez BulletinDate i ResponseDate (który kiedyś był CreatedDate ), aby umożliwić wiele odpowiedzi na User na Bulletin .

Komentarze dotyczące trzeciego modelu danych i odpowiedzi

Zaufaj, że miałeś dobrą przerwę.

1. Co najmniej 30 lat temu (o czym jestem świadomy) giganci w branży mieli tę debatę. Imiona są zawsze w liczbie pojedynczej. Tabele są rzeczownikami. VerbFrazy to czasowniki. Nie ogranicza się to do konwencji nazewnictwa baz danych, dotyczy to dokumentów, tez, dysertacji itp. Możesz mieć 5 wniosków na końcu dokumentu, ale tytuł sekcji lub rozdziału, zarówno w ToC, jak i na górze strony to „Wniosek”.

   Po walce z nimi przez cały Uni, gdy tylko zacząłem swoją pierwszą płatną pracę programistyczną i zobaczyłem znaczenie reguł w prawdziwym świecie, w przeciwieństwie do teoretycznych argumentów, które mieliśmy na studiach, zrezygnowałem z tego jako marnotrawstwo czasu. Cały ten czas i energię, które zmarnowałem, zostały uwolnione do produktywnej pracy. Od tego czasu nie kwestionuję gigantów; Po prostu akceptuję. Że ich umysły są większe niż moje. To jest jak akceptowanie norm lub postępowanie zgodne z prawem lub Bogiem. Nie mam naprawdę dobrych powodów, by robić cokolwiek nielegalnego.

   Zresztą łatwość posługiwania się językiem (dyskusja, SQL, dokumentacja), którą wspierają takie reguły, nie może być odpowiednio wyjaśniona; gdy będziesz pisać coraz więcej kodu SQL, stanie się to jasne.

   Zawsze możesz używać tego, co chcesz. Dostarczam tylko w liczbie pojedynczej.

2. Nie mam nic przeciwko.

   Należy jednak pamiętać, że te dwa elementy w zidentyfikowanej kolejności (ala non-PK Unique Index lub Alternate Key) są powszechnie wymagane do ustalenia unikalności osoby. Usunięcie ich spowoduje dwie rzeczy. Po pierwsze, nie będziesz już w stanie zidentyfikować niepowtarzalności wśród Users (a zatem możesz mieć zduplikowane wiersze). Po drugie, AK staje się nieunikatowe, wpis inwersji.

3. Chodzi o to (w przeciwieństwie do jednego z postów), dowolna kolumna, która jest 1::1 z User PK, powinien znajdować się w User . Wszystkie ustawienia preferencji. Ponieważ wyczyściliśmy InterestedLocations iInterestedCategories , znam tylko BulletinsPerPage pozostały; ale jestem pewien, że są inni. IsPreference2 jest np. wartości logicznej;NumPreference3 jest np. liczby całkowitej. Itd. Możesz mi powiedzieć, jakie są prawdziwe Preferencje.

   (Spróbujmy tego w liczbie mnogiej:... dowolna kolumna, która jest 1::1 z Users PK, powinien znajdować się w Users . Po prostu nie robi tego za mnie, rozłączam się z łamaną angielszczyzną i jestem trochę cenny w moim języku ojczystym.)

   Zaktualizowano model danych.

4. Doskonały. Daj mi znać, kiedy ci to odpowiada, a dam ci model fizyczny.

   A co z czasownikami?

Komentarze do 06 grudnia 10, 20:38 EST (małe aktualizacje)

.
28. Tam, gdzie występuje tylko jedno wystąpienie PK jako FK, oczywiście nazwa kolumny FK jest taka sama jak nazwa kolumny PK. Jednakże, gdy w FK jest więcej niż jedno occ (spójrz na ResponseRating ), istnieją trzy UserIds ), musimy je rozróżnić. W terminologii IDEF1X nazywa się to rolami. Rola User kto wydał Bulletin jest Issuer , i tak dalej. Oczywiście lepiej jest używać tej nazwy i utrzymywać ją spójną w całej hierarchii (nie UserId w Bulletin a potem gdy dojdziemy do Response , gdzie są dwa i wymagane jest rozróżnienie, zmień go na IssuerId . Pomyślałem, że możesz mieć z tym problem; we wczesnych stadiach użycie to Issuer.UserId aby było absolutnie jasne, że jest to UserId jako FK, a rolą jest Issuer; kiedy dochodzimy do modelu fizycznego, zostaje on uproszczony do IssuerId .

Podobnie mamy wiele kolumn DateTime (w skrócie Date, jeśli chcesz; w przeciwnym razie Dtm), które należy rozróżnić.
.
29. Czy dokument IDEF1X Notation nie miał sensu?

• PK dla każdego stołu znajduje się powyżej linii, w określonej kolejności.
• Pamiętaj, że i tak nosimy PK tabel nadrzędnych, a jeśli ma to znaczenie, użyj tych FK do utworzenia potomnej PK.

• Dla Bulletin :

  • Lokalizacja FK (StateCode, Town) dla którego jest wydawany
  • UserId Emitenta
  • i Data i godzina wydania, aby była unikalna.
  • dlatego (StateCode, Town, IssuerId, BulletinDate)`

• Aby usunąć wszystkie ResponseRatings dla tego Bulletin , użyj WHERE = na tych czterech Bulletin kolumny.

.
30. Ponieważ (State, Town) to PK Location , niosąc wszędzie. I stanowi część Bulletin PK, więc wszystkie tabele zależne zawierają te kolumny, ponieważ zawierają Bulletin PK.

Wcześniej zidentyfikowaliśmy, że (State, Town) jest PK, zostawię to bez zmian Patrz (38) dla zmian.

.
33. Warto omówić. Tak, jeśli masz zamiar wyświetlić go podczas (np.) wyświetlania Response , a użytkownicy rozumieją UserName . Nie, jeśli ma 30 bajtów i istnieje również unikalny 4-bajtowy UserId . Chodzi o to, aby świadomie dokonywać tych wyborów, mając świadomość tego, z czego rezygnujesz, kiedy w końcu zdecydujesz, że jakiś 6-kolumnowy 30-bajtowy klucz jest zbyt nieporęczny, aby przenieść go na dzieci.

• Na początku stwierdziłem, że użyłbym UserId jako typowy Id Pk, ponieważ jest przenoszony/migrowany do kilku tabel podrzędnych.
• Sposób tworzenia możemy zostawić na później. Ale to czysty surogat PK.

.
34. Nie ma problemu. Category już to ma. Zmienię Order do ListOrder .

.
35. Pewny. Opierając się na tym, co przeczytałem i usłyszałem, jestem z tego całkiem zadowolony. Ale chciałbym, aby więcej tam i z powrotem nabrało pewności, zanim zaczniesz pisać kod. Ewentualnie potraktuj to jako doświadczenie edukacyjne i zaakceptuj, że model i kod mogą się później zmienić. Czy chcesz, żebym teraz wyprodukował Fizyczną? Jeśli dacie mi jakieś poprawki, opublikuję kolejną wersję. Oczekuję preferencji w User . Ponadto szybko przejrzyj funkcje i sprawdź, czy masz wszystkie potrzebne kolumny.

Przyjrzyj się niektórym innym odpowiedziom w celu uczenia się i zainteresowania.

.
36. Łączy. Po prostu dołączasz do czterech trzy kolumny w przeciwieństwie do jednej. SQL jest kłopotliwy z łączeniami, a nowa składnia, która miała to ułatwić, jest w rzeczywistości bardziej kłopotliwa. Moi programiści nigdy nie piszą złączeń:oszczędzamy czas i literówki. Mam proc, który biorąc pod uwagę dwie lub więcej tabel, wygeneruje kod ze wszystkimi kolumnami i złączeniami. Nie znam wystarczająco MySQL, aby to dla Ciebie przekonwertować.

Zaktualizowano model danych.
.

Komentarze do 08.10.10, 20:49, Czwarty model danych i odpowiedzi

.
Sprawdź poprzednią sekcję bezpośrednio powyżej, są małe aktualizacje.

IDEF1X:Twoja prędkość jest w porządku.

Zwróć uwagę na dziecko zawsze „dziedziczy” PK nadrzędne, jako FK (linia ciągła lub przerywana), w przeciwnym razie nie ma między nimi relacji. Używając tych kolumn, które i tak istnieją w dziecku, aby utworzyć dziecko PK, nosimy znaczenie (i to jest różnica między solidnym a zepsutym). I tym samym nie musimy szukać samodzielnego Identyfikatora dla dziecka. Siła relacyjna w tej metodzie stanie się jasna później, podczas kodowania.

Sekcja, którą się zajmujemy, dotyczy identyfikatorów :naturalne vs nienaturalne; znaczące vs bezsensowne. Później zobaczysz, jak możemy wykorzystać relacyjną zdolność silnika, gdy PK potomny jest tworzony z PK rodzica. (Czy twoje nazwisko nie jest takie samo jak twojego ojca?)

Ważne jest również zrozumienie relacyjnych baz danych i ich możliwości. Tracimy to, gdy podchodzimy do bazy danych (np.) z perspektywy OO i traktujemy ją jako lokalizację, dzięki której nasze klasy są „trwałe”. Dlatego postaramy się nauczyć i używać pojęć relacyjnych. Robi się trudno, gdy jedziesz do Francji i oczekujesz, że mówią po amerykańsku i używają tej samej waluty; naucz się mówić 10 słów po francusku, a witają cię z otwartymi ramionami, a będziesz miał zupełnie inne doświadczenia z mieszkańcami.

W każdym razie kontynuuj wdrożenie modelu. Po prostu zdaj sobie sprawę, że prawdopodobnie w pewnym momencie dokonamy zmiany. Zapisz wszystkie swoje DDL. Zapisz wszystkie dane testowe jako instrukcje wstawiania lub jako kopię zapasową tabeli lub eksport formatu znaków (nie mam pojęcia, co MySQL może/nie może zrobić w tym obszarze).
37.1. Obsługiwana relacja n::n z Office &Category . Zobaczysz to dopiero, gdy dojdziemy do modelu fizycznego.

37.2. Gotowe.

37.3 Gotowe.
.
38. Doskonały. Również krótsze. Pamiętaj, że nigdy nie będą mogli mieć dwóch Offices w tym samym kodzie pocztowym. NUMERIC(5,0) jest dobry, ale myślałem, że USA zmierzają w kierunku 7 cyfr. Nie ma znaczenia, możesz to rozgryźć; to doskonały pakiet PK dla Office . Teraz ta kolumna, która była częścią Address , prawdopodobnie ZipCode , został wyniesiony do wyższego celu, bez powielania; ponieważ przechowujemy go w 5 tabelach podrzędnych i chcemy, aby nazwa PK była jasna, zgodnie z wcześniej wyjaśnionymi konwencjami, nazwiemy ją OfficeCode; OfficeZipCode może być głupie.

Potrzebujemy unikalnego indeksu dla Name aby upewnić się, że nie dodadzą dwóch Offices o tej samej nazwie. Uwaga, w celu wyjaśnienia, jest to w rzeczywistości klucz logiczny Office , zastępując (StateCode, Town) , i tak pozostaje.

Nadal uważam, że możesz potrzebować StateCode i Town jako szybkie odniesienie (inne niż siedzenie gdzieś w Address )

Zaktualizowano model danych, piąty jest już dostępny do przeglądu. Nie określiłeś swoich preferencji dla ...Date vs ...Dtm . Idę z tym drugim, ponieważ jest bardziej konkretny, identyfikując również składnik czasu. Łatwa zmiana.

Ta odpowiedź osiągnęła maksymalną długość. Ciąg dalszy w „Części II”