Табло за обяви - Оптимизация на база данни

.
22.3. Трябва да разберете защо, изобщо не е проблем. Само децата сляпо следват прости правила, а вие със сигурност не сте от тях.
.
23. Потвърдено:users.total_bulletins е излишен; може да се извлече. Премахнато.
.
24. Всичките ви PK са идентификатори. Още ли не ви омръзна да се губите в кода? Забравете за залепването на Id iot PK за всичко, което се движи, нека разберем как вашите потребители Идентифицирайте техните субекти; кои обекти са наистина независими, а другите, които зависят от независими субекти.

24.1. Никога не използвайте Id или всякаква такава форма. Когато е PK, използвайте пълния формуляр.

24.2. Обадете се на location_id, location_id, където и да е, включително PK таблицата. Изключението е, когато трябва да покажете ролята. Това ще стане ясно в модела на данни.
.
25. Нямате декларативна референтна цялост, нямате дефинирана Чужди ключове. Това е лоша новина по много различни причини. След като тези въпроси бъдат изяснени, моля, добавете ги. DRI означава, че колкото е възможно повече, ако не и цялата, целостта се декларира в SQL. Стандартът ISO/IEC/ANSI SQL позволява това, но безплатният край на пазара не предоставя стандарта и бавно наваксва. Това означава, че сървърът няма да позволи добавянето на ред в таблицата FK, освен ако PK не съществува в родителската таблица. MySQL наскоро предостави DRI за чужди ключове. За FK вижте ▶ тази статия◀ .

25.1. За CHECK ограничения и ПРАВИЛА ще трябва да ги внедрите в код.

Външните ми ключове са като, users-id(fk) =users.id(pk) Не съм сигурен как да ги добавя, освен това, което съм направил, но със сигурност ще го направя, след като знам как да го направя.

Двадесет и пет. Забелязани коментари. Не съм специалист по MySQL. Да, това са проблемите, които трябва да разберете сами. Като цяло, от моето разглеждане, MySQL е без крака; за каквото и да било SQL, имате нужда от InnoDB.

.
27. Като се има предвид:Преосмислих изискванията за сортиране на бюлетина. Потребителите могат да сортират хронологично - лесно, има смисъл. Потребителите могат да сортират бюлетините по датата на последния отговор на бюлетина. Тогава можем да забравим за ранга и би трябвало да е наистина лесно да сортирате бюлетините хронологично по времето на последния им отговор? Какви са вашите мисли.

Отворени проблеми

(Няла)

Модел на данни

Добре, ако приемем, че нямате проблеми с ERD и внедрявате всички затворени проблеми, моделирах данните и подготвих Пети модел на данни 09 декември 10 за вашия преглед. Определено ми трябватмного повече обратна връзка, въпроси и т.н. по този въпрос. Изпитвам трудности да приема, че е направено. Вероятно е най-добре да започнете да пишете истински код за вашите проблемни области.

Връзки

▶Връзка към нотация IDEF1X◀ Наистина трябва да прочетете и разберете това, преди да прочетете Модела на данни.

▶Връзка към данните от петия бюлетин Модел◀ Диаграма за връзки на субект е на първа страница, следван от модела на данни .

• Ключовете са доста прави IDEF1X (с изключение на UserId, който предоставих като контрапункт); което означава релационни ключове на портмоне. Не е подобрен и не е оптимизиран за физически съображения. Преди да се захванете с тях, първо ги забележете, регистрирайте ги и ги оценете. Разбира се, че можем да доставаме Id iot keys, но преди да направим това, нека се уверим, че разбираме какво ще загубим.

• Обърнете внимание на идентификаторите (плътни линии) съгласно документа за нотации. Гръбначният стълб, прешлените на системата е Location ... Bulletin ... Response .

• Забележете, че Keys всъщност прилага много бизнес правила.

• Забележете Естествената йерархия, която изобразих. Вижте дали има някакъв смисъл в това за вас.

• Глаголните фрази са наистина важни; вижте дали означават нещо.

Коментари за първия модел на данни и отговори

Един въпрос, който имам, е, че първичният ключ на местоположението ще се използва за формиране на дъщерния първичен ключ? (те са свързани с плътна линия) Наистина не разбирам тази концепция

• Какво е добрият идентификатор за бюлетин? , какво естествено използват вашите потребители, за да идентифицират бюлетин ...
• „виждали ли сте бюлетина от Virginia FO вчера?“,
• „Сали от Вашингтон със сигурност пише добри бюлетини“ и т.н.

или защо тази връзка не съществува между потребителя и бюлетина?

• Съгласно намерението, посочено по-горе, тъй като сега показах Рейтинг като таблица и какво ще бъде изобразяването, веднъж ще го премахна

• Мисля, че разрешението трябва да бъде обект.

• Bulletin PK вече е (StateCode, Town, UserId, SequenceNo) . За да бъде ясно, SequenceNo е в рамките на StateCode, Town, UserId :ще бъде 5 за 5-ия бюлетин на Сали за MO/Billngs FO.

• Имайте предвид, че потребителски настройки BulletinsPerPage и т.н. са 1::1 с User , така че те са в User; дъщерната таблица би била неправилна.

• Коригирани печатни грешки.

Коментари за втория модел на данни и отговори

• ПК за двата Bulletin и Response са променени, за да отразяват (7). BulletinNo и ResponseNo са заменени с BulletinDate и ResponseDate (който е бил CreatedDate ), за да разрешите множество отговори на User за Bulletin .

Коментари за третия модел на данни и отговори

Вярвайте, че сте си изкарали добра почивка.

1. Преди поне 30 години (за което знам) гигантите в индустрията имаха този дебат. Имената винаги са единствени. Таблиците са съществителни. Глаголните фрази са глаголи. Това не е ограничено до конвенциите за именуване на db, то се отнася за документи, тези, дисертации и т.н. Може да имате 5 заключения в края на документа, но заглавието на раздел или глава, както в общите условия, така и в горната част на страницата е "Заключение".

   След като се борих с тях по целия път през Uni, веднага щом започнах първата си платена работа по програмиране и видях важността на правилата в реалния свят, за разлика от теоретичните аргументи, които имахме в колежа, се отказах от това като загуба от време. Цялото това време и енергия, които пропилях, бяха освободени, за да върша продуктивна работа. Оттогава не поставям под въпрос гигантите; просто приемам. Че техните умове са по-големи от моите. Това е като приемане на Стандарти, или поведение в рамките на закона, или Бог. Нямам наистина, наистина основателни причини да правя нещо незаконно.

   Така или иначе, лекотата на езика (дискусия, SQL, документация), която се поддържа от такива правила, не може да бъде адекватно обяснена; като пишете все повече и повече SQL код, ще стане ясно.

   Винаги сте свободни да използвате каквото пожелаете. Предоставям само единствено число.

2. Добре с мен.

   Но трябва да имате предвид, че тези два елемента в идентифицираната последователност (ала не-PK уникален индекс или алтернативен ключ) са универсално необходими за установяване на уникалност за лице. Премахването им ще доведе до две неща. Първо, вече няма да можете да идентифицирате уникалността на Users (и по този начин може да имате дублиращи се редове). Второ, AK става неуникален, инверсионен запис.

3. Въпросът е (противно на една от публикациите), всяка колона, която е 1::1 с User PK, трябва да се намира вUser . Всички настройки за предпочитания. Тъй като изчистихме InterestedLocations иInterestedCategories , знам само за BulletinsPerPage оставащ; но съм сигурен, че има и други. IsPreference2 е напр. на булева;NumPreference3 е напр. на цяло число. И т.н. Можете да ми кажете какви са истинските предпочитания.

   (Нека опитаме това в множествено число:... всяка колона, която е 1::1 с Users PK, трябва да се намира вUsers . Просто не го прави вместо мен, зациклям се на развален английски и съм малко ценен за майчиния си език.)

   Моделът на данните е актуализиран.

4. Отлично. Кажете ми, когато се чувствате комфортно с това, и ще ви дам физическия модел.

   Какво ще кажете за глаголните фрази?

Коментари от 06 декември 10 20:38 EST (малки актуализации)

.
28. Когато има само едно появяване на PK като FK, разбира се, името на FK колона е същото като името на колона PK. Въпреки това, когато има повече от един occ на FK (вижте ResponseRating ), има три UserIds ), трябва да ги разграничим. В терминологията на IDEF1X това се нарича роли. Ролята на User който е издал Bulletin е Issuer , и така нататък. Очевидно е по-добре да използвате това име и да го поддържате последователно в цялата йерархия (не UserId в Bulletin и след това, когато стигнем до Response , където има две и се изисква диференциация, променете го на IssuerId . Мислех, че може да имате проблем с това; в ранните етапи използването е Issuer.UserId така че да е абсолютно ясно, че това е UserId като FK, а ролята е Issuer; когато стигнем до физическия модел, той се опростява до IssuerId .

По същия начин имаме много колони DateTime (Date за кратко, ако желаете; в противен случай Dtm), които трябва да бъдат разграничени.
.
29. Документът за нотация IDEF1X нямаше ли смисъл?

• PK за всяка таблица е над реда, в посочения ред.
• Не забравяйте, че така или иначе носим PK на родителските таблици и ако има смисъл, използваме тези FK за формиране на дъщерния PK.

• За Bulletin :

  • Местоположението FK (StateCode, Town) за които е издаден
  • UserId на емитента
  • и DateTime е издаден, за да стане уникален.
  • следователно (StateCode, Town, IssuerId, BulletinDate)`

• За да изтриете всички ResponseRatings за този Bulletin , използвайте WHERE = за тези четири Bulletin колони.

.
30. Защото (State, Town) е PK на Location , носейки навсякъде. И е част от Bulletin PK, така че всички зависими таблици носят тези колони, защото носят Bulletin PK.

По-рано идентифицирахме този (State, Town) е PK, ще оставя това както е Вижте (38) за промяна.

.
33. Заслужава си дискусия. Да, ако ще го покажете при (напр.) показване на Responses , а потребителите разбират UserName . Не, ако е 30 байта и има също уникален 4 байта UserId . Идеята е да направите тези избори съзнателно, наясно от какво се отказвате, когато в крайна сметка решите, че някакъв 6 колонен 30-байтов ключ е твърде тромав, за да мигрира към децата.

• Заявих в началото, че ще използвам UserId като типичен Id Pk, защото се пренася/мигрира към няколко дъщерни таблици.
• Можем да оставим как е създадено за по-късно. Но това е чист сурогатен PK.

.
34. Няма проблем. Category вече го има. Ще променя Order към ListOrder .

.
35. Сигурен. Според това, което прочетох и чух, съм доста доволен от него. Но бих искал повече напред-назад, за да постигна известна увереност, преди да пишете код. Алтернативно, гледайте на това като на учебно изживяване и приемете, че моделът и кодът може да се променят по-късно. Искате ли сега да продуцирам физическото? Ако ми дадете някакви корекции, ще публикувам следващата версия. Очаквам предпочитания в User . Освен това бързо преминете през функциите и проверете дали имате всички необходими колони.

Погледнете някои от другите отговори с цел учене и интерес.

.
36. Присъединява се. Просто се присъединявате на четири три колони за разлика от една. SQL е тромав с присъединяванията, а новият синтаксис, който трябваше да го улесни, всъщност е по-тромав. Моите кодери никога не пишат присъединявания:спестяваме време и печатни грешки. Имам процедура, която дава две или повече таблици, ще генерира кода с всички колони и съединения. Не познавам достатъчно MySQL, за да го конвертирам вместо вас.

Моделът на данните е актуализиран.
.

Коментари относно 08 декември 10, 20:49, четвърти модел на данни и отговори

.
Проверете предишния раздел непосредствено по-горе, има малки актуализации.

IDEF1X:Скоростта ви е добра.

Обърнете внимание на дететовинагита "наследява" родителския PK, като FK (или плътна, или прекъсната линия), в противен случай няма връзка между тях. Като използваме тези колони, които така или иначе съществуват в детето, за да формираме дъщерния PK, ние носим значението (и това е разликата между твърди и счупени). И по този начин не е необходимо да търсим независим идентификатор за детето. Релационната сила в този метод ще стане ясна по-късно, когато кодирате.

Разделът, с който се занимаваме, е за Идентификатори :естествено срещу неестествено; смислен срещу безсмислен. По-късно ще видите как можем да използваме релационните възможности на двигателя, когато дъщерният PK се формира от родителския PK. (Фамилията ви не е ли същата като тази на баща ви?)

Също така е важно да се разбират релационните бази данни и техните възможности. Това се губи, когато подходим към базата данни (например) от гледна точка на OO и я третираме като място, за да направим нашите класове "постоянни". Затова ще се опитаме да научим и използваме релационни термини. Става трудно, когато отидеш във Франция и очакваш, че говорят американски и използват същата валута; научете се да говорите 10 думи на френски и те ви приветстват с отворени обятия и ще имате съвсем различно преживяване с местните жители.

Както и да е, продължете с прилагането на модела. Просто осъзнайте, че вероятно ще направим промяна в някакъв момент. Запазете всичките си DDL. Запазете всичките си тестови данни като изрази за вмъкване или като резервно копие на таблица или експортиране във формат на символи (няма идея какво може/не може да направи MySQL в тази област)..
37.1. Обработено, връзката n::n с Office &Category . Ще "видите" това едва когато стигнем до физическия модел.

37.2. Готово.

37.3 Готово.
.
38. Отлично. По-кратък също. Имайте предвид, че те никога няма да могат да имат два Offices в същия пощенски код. NUMERIC(5,0) е добре, но аз мислех, че САЩ се движат към 7 цифри. Няма значение, можете да го разберете; това е отличен PK за Office . Сега тази колона, която беше част от Address , вероятно ZipCode , е издигнат до по-висока цел, без дублиране; тъй като го носим в 5 дъщерни таблици и искаме името на PK да е ясно, съгласно обяснените по-горе конвенции, ще го наречем OfficeCode; OfficeZipCode може да е глупаво.

Нуждаем се от уникален индекс на Name за да се гарантира, че няма да добавят два Offices със същото име. Забележете, за обяснение, това всъщност е логическият ключ на Office , замествайки (StateCode, Town) , и остава така.

Все още мисля, че може да имате нужда от StateCode и Town като бърза справка (освен някъде в Address). )

Моделът на данни е актуализиран, петият вече е наличен за преглед. Не сте посочили предпочитанията си за ...Date срещу ...Dtm . Отивам на последното, тъй като е по-конкретно, идентифицирайки и времевия компонент. Лесна за смяна.

Този отговор достигна максимална дължина. Продължение в "Част II"та