W oparciu o analizę wymagań, zdecydowaliśmy się używać następującej bazy danych w celu przechowywania trwałych danych dla naszej aplikacji blogowej:
tbl_user
przechowuje informacje o użytkownikach, włączając w to ich nazwy oraz hasła. tbl_post
przechowuje informacje o postach w blogu. Składa się ona przede wszystkim z następujących kolumn:
title
(tytuł): wymagany, tytuł wiadomości;content
(zawartość): wymagana, zawartość treści wiadomości, zapisana w formacie Markdown;status
(status): wymagany, status wiadomości, który może przyjmować następujące wartości:
tags
(otagowanie): opcjonalne, lista rozdzielonych przecinkami słów, kategoryzujących wiadomość.tbl_comment
przechowuje informacje o komentarzach do wiadomości. Każdy komentarz jest powiązany z wiadomością i przede wszystkim zawiera następujące kolumny:
author
(autor): wymagana, nazwa autora komentarza;email
(email): wymagany, e-mail autora komentarza;url
(strona WWW): opcjonalna, strona WWW autora komentarza;content
(zawartość): wymagana, zawartość komentarza zapisanego w formacie tekstowym.status
(status): wymagany, status komentarza determinujący czy komentarz został zatwierdzony (wartość 2) lub nie (wartość 1).tbl_tag
zawiera informację o częstotliwości występowania tagów, która jest potrzebna do zaimplementowania chmury tagów. Tabela ta zawiera przede wszystkim następujące kolumny:
name
(nazwa): wymagana, unikalna nazwa tagu;frequency
(częstotliwość): wymagana, ilość występowań tagu w wiadomościach;tbl_lookup
zawiera ogólne, przeglądowe informacje. Jest to w istocie tabela pomiędzy wartościami liczbowymi a tekstami. Pierwsze są reprezentacją danych w naszym kodzie, drugie zaś odpowiadają tekstom prezentowanym użytkownikowi końcowemu. Na przykład, używamy wartości numerycznej 1 do reprezentowania wersji tymczasowej wiadomości a łańcucha znaków Draft
w celu wyświetlenia tego statusu użytkownikowi końcowemu. Tabela ta zawiera przede wszystkim następujące kolumny:
name
(nazwa): tekstowa reprezentacja pozycji danych, która zostanie wyświetlona użytkownikowi końcowemu; code
(kod): wartość numeryczna, reprezentująca pozycję danych;type
: typ pozycji danych;position
(pozycja): względna kolejność pozycji danych pośród innych pozycji tego samego typu. Następujący diagram (ER) relacji encji (ang. entity-relation diagram), pokazuje strukturę oraz relacje dla wyżej opisanych tabel.
Diagram relacji encji dla bazy danych blogu
Wszystkie wyrażenia SQL odpowiadające powyższemu diagramowi ER, można znaleźć w demonstracyjnym blogu. Dla naszej instalacji Yii, można je odnaleźć w pliku /wwwroot/yii/demos/blog/protected/data/schema.sqlite.sql
.
Informacja: Nazwaliśmy wszystkie nasze tabele używając małych liter. Kierowaliśmy się tym, ponieważ różne DBMS często w różny sposób traktują wielkość liter a chcieliśmy uniknąć takich kłopotów.
Poprzedziliśmy wszystkie cztery tabele prefiksem
tbl_
. Służy to dwóm celom. Po pierwsze, prefiks wprowadza przestrzeń nazw do tych tabel w przypadku, gdy muszą one współistnieć z innymi tabelami w tej samej bazie danych, co zdarza się często w współdzielonych środowiskach hostujących, gdzie pojedyncza tabela jest używana przez wiele aplikacji. Po drugie, używanie prefiksów nazw tabel redukuje prawdopodobieństwo posiadania nazwy tabeli, która jest jednocześnie zarezerwowanym słowem kluczowym w DBMS.
Proces tworzenia naszej aplikacji podzieliliśmy na następujące kamienie milowe.
Found a typo or you think this page needs improvement?
Edit it on github !
Signup or Login in order to comment.