Implementacja bazy została przeprowadzona zgodnie z diagramem ERD opracowanym w fazie projektowania. Kod sql do utworzenia bazy
BEGIN;
CREATE TABLE "accounts_contactdata" (
"id" integer NOT NULL PRIMARY KEY,
"city" varchar(100),
"street" varchar(100),
"flat_number" varchar(10),
"pna" varchar(6),
"phone" varchar(12),
"lat" float,
"lng" float
)
;
CREATE TABLE "accounts_userprofile" (
"id" integer NOT NULL PRIMARY KEY,
"user_id" integer NOT NULL UNIQUE REFERENCES "auth_user" ("id"),
"contact_data_id" integer NOT NULL REFERENCES "accounts_contactdata" ("id"),
"activation_key" varchar(40) NOT NULL
)
;
CREATE TABLE "accounts_comment" (
"id" integer NOT NULL PRIMARY KEY,
"user_comment" text NOT NULL,
"ratio" integer unsigned NOT NULL,
"user_id" integer REFERENCES "accounts_userprofile" ("id"),
"restaurant_id" integer REFERENCES "restaurants_restaurant" ("id"),
"dish_id" integer REFERENCES "restaurants_dish" ("id")
)
;
CREATE TABLE "accounts_basket" (
"id" integer NOT NULL PRIMARY KEY,
"user_id" integer REFERENCES "accounts_userprofile" ("id"),
"session" varchar(32)
)
;
CREATE TABLE "restaurants_restaurant" (
"id" integer NOT NULL PRIMARY KEY,
"user_id" integer NOT NULL UNIQUE REFERENCES "auth_user" ("id"),
"is_promo" bool NOT NULL,
"activation_key" varchar(40) NOT NULL,
"contact_data_id" integer NOT NULL UNIQUE REFERENCES "accounts_contactdata" ("id"),
"description_id" integer NOT NULL
)
;
CREATE TABLE "restaurants_dish" (
"id" integer NOT NULL PRIMARY KEY,
"name" varchar(100) NOT NULL,
"description" varchar(500) NOT NULL,
"price" varchar(7) NOT NULL,
"category_id" integer NOT NULL,
"restaurant_id" integer NOT NULL REFERENCES "restaurants_restaurant" ("id")
)
;
CREATE TABLE "restaurants_category" (
"id" integer NOT NULL PRIMARY KEY,
"name" varchar(200) NOT NULL,
"restaurant_id" integer NOT NULL REFERENCES "restaurants_restaurant" ("id")
)
;
CREATE TABLE "restaurants_description" (
"id" integer NOT NULL PRIMARY KEY,
"name" varchar(200) NOT NULL,
"description" text,
"img" varchar(100) NOT NULL
)
;
CREATE TABLE "restaurants_orderingdish" (
"id" integer NOT NULL PRIMARY KEY,
"count" integer unsigned NOT NULL,
"dish_id" integer NOT NULL REFERENCES "restaurants_dish" ("id"),
"basket_id" integer REFERENCES "accounts_basket" ("id"),
"order_id" integer
)
;
CREATE TABLE "restaurants_order" (
"id" integer NOT NULL PRIMARY KEY,
"state" varchar(1) NOT NULL,
"order_date" datetime NOT NULL,
"contact_data_id" integer NOT NULL REFERENCES "accounts_contactdata" ("id"),
"restaurant_id" integer NOT NULL REFERENCES "restaurants_restaurant" ("id"),
"order_time" varchar(100)
)
;
COMMIT;
Dla użytkowników będących administratorami lub moderatorami wykorzystaliśmy wbudowany w Django panel administratora.
Dla zarządzania restauracją został stworzony oddzielny panel
W projekcie został wykorzystany maper obiektowo-relacyjny wbudowany w Django, który realizuje za nas operacje potrzebne do obsługi bazy danych.
Aplikacja była głównie testowana na serwerze lokalnym, na którym zostały uzyskane pozytywne rezulaty. Przeprowadzane testy były to głównie metody Black-box.
Pierwszy rozdaj testów to testy funkcjonalne przeprowadzane przez przez developerów aplikacji na częściach systemu pisanych przez innych programistów, co miało na celu zwiększenie jakości testów. Przeprowadzone zostały także testy użyteczności, wykonywane przez trójkę kolegów ze studiów. Ich zadaniem było przeklikanie wszystkich funkcji naszego systemu, zarówno po stronie klienckiej jak i restauracji.
Testy funkcjonalne wykazały kilka błędów w funkcjonowaniu zapytań do bazy, co zostało skutecznie naprawione. Informacja zwrotna na temat testów użyteczności była zadowalająca, to jest aplikacja nie sprawiała problemów w użytkowaniu oraz nasi koledzy nie napotkali problemów z jej działaniem oraz procesem realizacji zamówień.
Testy wydajnościowe zostały przeprowadzone pod kątem dużej ilości restauracji oraz dużej liczby potraw w bazie - dane zostały wygenerowane automatycznie. Przy 100 restauracjach czas odpowiedzi był w przedziale 0,2-0,5s co w naszym mniemanie jest zadowolające. Testy pod kątem dużej liczby w miare współbieżnych operacji wykonywach przez klientów nie zostały przeprowadzone i zamierzamy dopiero zwrócić na to szczególną uwagę, gdy faktycznie w naszym portalu zarejestruje się już spora liczba użytkowników. Na chwile obecną przy niewielkiej liczbie składanych zamówień na ma powodów do obaw pod względem spadku wydajności pracy.
Czego nie udało się przeprowadzić to testy bezpieczeństwa oraz co najważniejsze testy akceptacyjne (głównie strona resturacji). Jako, że system wykorzystuje Django, mamy powody sądzić, że jest dobrze zabezpieczony pod kątem ataków z zewnątrz, niemniej jednak nie mamy 100% pewności. Testy akceptacyjne powinny być zasadniczo przeprowadzone prze klientów systemu. Jako, że takowi nie zostali bezpośrednio wykorzystywani przy definiowaniu funkcji systemu, będziemy w stanie ocenić to dopiero po prezentacji naszej aplikacji konkrentym lokalom serwującym jedzenie. Na podstawie takich informacji zostaną podjęte kolejne decyzje odnośnie przebudowy lub rozwinięcia systemu.
Na koniec warto wspomnieć, że testy lokalne były wykonywane na SQLite. Przejście na Postgresql jest planowane wraz z uruchomieniem systemu na serwerze zewnętrznym.
W aplikacji nie ma potrzeby automatycznego wprowadzania danych. Wszelkie dane wprowadzane są przez użytkowników poprzez formularze dostępne na stronie aplikacji. Wraz z dołączaniem kolejnych użytkowników oraz restauracji baza danych jest wzbogacana o informacje.
Wdrożenie systemu polega na stworzeniu struktury bazy na serwerze bazodanowym oraz postawienie aplikacji na serwerze obsługującym hosting Python'a. Jedyną wymaganą czynnością jest konfiguracja pliku połączenia do bazy danych. Wiąże się to oczywiście z kosztami zakupu serwera lub miejsca na takowym. Po tych czynnościach aplikacja dostęp do aplikacji jest udostępniony przy pomocy przeglądrki internetowej, zarówno dla strony klientków jak i restauracji.
Obsługa systemu z punktu widzenia zamawiającego nie jest skomplikowana i zasadniczo jest on przeprowadzany krok po kroku przez proces zamówienia.
Restauracje przystępujące do systemu potrzebują mieć swojej siedzibie komputer z stałym podłączeniem do internetu, tak aby nie zachodziły problemy z niewykonanymi lub zbyt długo oczekującymi zamówieniami. W przypadku gdy restauracja nie ma dostępu do portalu powinna niezwłocznie skontaktować się z obsługą serwisu w celu tymczasowego zablokowania możliwości składania zamówień na potrawy z owej restauracji. Wdrożenie po stronie lokalu wiążes się także z krótkim szkoleniem przedstawiającym pracowanikom jak działa nasz system oraz jak powinno się poprawnie obsługiwać zamówienia.
Aplikacja nie jest skomplikowana a interfejs bardzo intuicyjny. Samo zamawianie potraw nie powinno sprawiać problemów dla kientów systemu.
Szkolenie dla pracowników restauracji będzie organizowane po dołączeniu danego lokalu do naszej spółki. Przeprowadzana jest krótka prezentacja zawierający schemat postępowania podczas przyjmowania i realizacji zamówień.
Z punktu widzenia klienta potrzebna jest tylko dokumentacja użytkowa po stronie zarządzania restauracją. Nieniejsza dokumentacja projektu zapewnia taki opis.
Zapewnienie obsługi systemu wiąże się z utrzymywaniem stabilnego serwera oraz spójnej bazy danych. W przypadku wystąpienia jakiś problemów, zespół służy pomocą i stara się odpowiadać na wszystkie zgłoszenia naszych użytkowników. Zachodzi tutaj potrzeba skupienia się głównie na stronie lokali restauracji.
Co jakiś okres wymagana jest kontrola obciążenia pracy serwera oraz wydajności aplikacji. Wraz z biegiem czasu do systemu będą dołączać nowi użytkownicy, zarówno po stronie klienckiej jak i lokali. Z tego powodu przyrastająca liczba danych może skutkować w zwolnieniu pracy. Jak wspomniano wcześniej nie wszystko zostało przetestowane pod tym kątem, dlatego niezbędne są testy wydajnościowe w czasie rozwijania systemu, tak aby nasi użytkownicy mogli cieszyść się sprawnie działającą aplikacją.
Struktura aplikacji pozwala na dołączanie nowych funkcjonalności zarówna dla klientów zamawiających jak i restauracji. Z biegiem czasu chcemy zebrać informacje zwrotne i na tej podstawie udoskonalić produkt tak aby w jak największym stopniu odpowiadał potrzebom naszych klientów.
W najbliższym czasie planowane jest wzbogacenie systemu o możliwosć zarządzania fakturami oraz udoskonalenie geolokalizacji naszych klientów (wtyczka PostGis).
Warto wspomnieć, że aplikacja została tak zaprojektowana, że zasadniczo może służyć jako system obsługi zamówień dla dowolnego typu kuchni lub też może grupować kilka rodzaji pod jednym portalem.
Kolejnym etapem rozwoju aplikacji jest zakup profesjonalnej grafiki. Jest to kosztowna inwesytcja, niemniej jednak potrzebna aby nasz portal zyskiwał większy prestiż.
Podczas prac developerskich wykorzystaliśmy bazę SQLite, głównie z tego powodu, aby przyśpieszyć prace nad projektem. Przy SQLite nie jest wymagany silnik bazodanowych, a cała baza jest przechowywana w plikach. Dzięki takiemu podejściu zmiany w strukturze bazy mogły być dokonywane szybciej niż w przypadku standardowego rozwiązania z serwerem bazy danych.
Natomiast przy komercyjnym wykorzystaniu systemu należy jednakże zastosować już coś bardziej rozwiniętego niż SQLite, po ty by mieć pewność, że wydajność przy wielu użytkownikach i dużej liczbie danych będzie na odpowiednim poziomie. Celujemy w wykorzystanie właśnie silnika Postgresql podczas wdrażania aplikacji do ogólnego użytku.
Podsumowując nie napotkaliśmy zasadniczo na sytuacje, które blokowałyby lub utrudniały budowanie systemu, wynikających z zastosowania SQLite.
Stosowania narzędzi typu ORM jest bardzo przydatne i uprzyjemnia prace z bazą. Z punktu widzenia programisty jest to kluczowa funkcjonalność. Warto zwrócić uwagę na optymalizację zapytań. Na podstawie wygenerowanych takowych bezpośrednio przez Django, możemy sądzić, że złączenia są organizowane poprawnie a same zapytania nie wyglądają bardzo skomplikowane lub przesadzone. Jedyne co się rzuca w oczy, to bezpośrednie wyliczanie kolumn po komendzie SELECT. Nawet jeśli listujemy wszystkie kolumny, to zamiast gwiazdki są one wylistowane po nazwach. Co do samej czasu pracy, w oparciu o źródła internetowe jak dokumentacja Django i forum, można wnioskować że omawiany ORM całkiem sprawnie radzi sobie z optymalizacją zapytań do bazy danych.
Do wyświetlania dostępnych lokali wykorzystywane są mapy Google. Współpraca z nimi jest całkiem wygodna, gdyż dostarczone jest dobre wsparcie ze strony Google, tak więc wiekszość problemów można szybko rozwiązać. W początkowej fazie nie wzieliśmy pod uwagę skalowaloności, to jest jak mapy będą działać gdy zostanie dodana duża liczba restauracji. Aby temu zapobiec wprowadziliśmy domyślne wyświetlanie tylko tych lokacji które znajdują się najbliżej naszego klienta. Geolokalizacja następuje poprzez IP użytkownika zamawiającego w naszym systemie. Dzięki temu przewidujemy zwiększegnie wydajności systemu.
Na chwile obecną wyznaczanie współrzędnych jest przeprowadzane poprzez ręczne obliczenia, wyznaczenie pola oraz przeszukanie, które restauracja odpowiadają parametrom. Jako, że chcemy wykorzystać w najbliższej przyszłości Postgresql, ciekawym rozwiązaniem byłoby zaostowanie wtyczki PostGis, służącej jako wsparcie dla geolokalizacji. Uzyskalibyśmy dzięki temu większą elastyczność w pracy z współrzędnymi geograficznymi. Tutaj przykład wyznaczania wszystkich obiektów znajdujących się w odległości 100 metrów od punktu P(1000,1000):
SELECT * FROM GEOTABLE WHERE GEOM && GeometryFromText(’BOX3D(900 900,1100 1100)’,-1) AND Distance(GeometryFromText(’POINT(1000 1000)’,-1),GEOM) < 100;
Idąc dalej, samo Django oferuje wsparcie ORM dla omawianej wtyczki, dzięki czemu nie trzeba by skupiać się na niskopoziomowych zapytaniach a pracować na obiektach dostępnych z poziomu modeli frameworku.
Realizacja owego projektu przyniosła sporo pozytywnych doświadczeń. Bardzo ważnym aspektem jest poświęcenie odpowiedniej ilości czasu na zaprojektowanie poprawnego schematu bazy danych, tak aby wymagała ona jak najmniejszą liczbę poprawek. Występuje potrzeba aby zaplanować wszystkie szczegóły zanim przystąpi się do faktycznej implementacji. W naszych wcześniejszych projektach często zachodziała sytuacja, że baza danych była modyfikowana kilkukrotnie co wprowadzało zamęt i nieporządek. W tym projekcie efektem poprawnej specyfikacji bazy było znaczne przyśpieszenie prac na developmentem projektu.
Nie ma jednak co ukrywać, że nie udało nam się w 100% zaimplementować cały system bez zmian, i w trakcie pracy kilka takowych wynikło, które należało wykonać bezpośrednio w modelach bazodanowych. Niemniej jednak skupienie dużego wysiłku podczas projektowania i tak przyniosło porządany efekt.
