Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: projekt bazy danych + relacje
Forum PHP.pl > Forum > Bazy danych
MitS
Witam serdecznie,

projektuje sobie bazę danych no i co nie co zrobiłem, ale niestety nie wiem czy to co zrobiłem jest poprawne oraz czy takie rozwiązanie będzie wydajne w przyszłości przy większej ilości danych.

Model bazy:



Kod:
  1. CREATE TABLE supportPosts (
  2. idTicket INT UNSIGNED NOT NULL
  3. , idPost SMALLINT(2) UNSIGNED NOT NULL
  4. , title CHAR(150) NOT NULL
  5. , content TEXT
  6. , idSuperUser CHAR(6)
  7. , superuserSeen BOOL NOT NULL DEFAULT 0
  8. , userSeen BOOL NOT NULL DEFAULT 0
  9. , addDate DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
  10. , PRIMARY KEY (idTicket)
  11. );
  12. CREATE INDEX supportPost ON supportPosts (idTicket ASC, idSuperUser ASC);
  13.  
  14. CREATE TABLE support (
  15. idSupport SMALLINT(2) UNSIGNED NOT NULL AUTO_INCREMENT
  16. , idSuperUser CHAR(6) NOT NULL
  17. , nameSurname CHAR(47) NOT NULL
  18. , email CHAR(40) NOT NULL
  19. , superUserPosition CHAR(30)
  20. , accessRights SMALLINT(1) UNSIGNED NOT NULL DEFAULT 1
  21. , PRIMARY KEY (idSupport)
  22. );
  23. CREATE UNIQUE INDEX support ON support (idSuperUser ASC, email ASC);
  24.  
  25. CREATE TABLE supportTickets (
  26. idTicket INT UNSIGNED NOT NULL
  27. , idAccount SMALLINT(5) UNSIGNED NOT NULL
  28. , title CHAR(150) NOT NULL
  29. , email CHAR(40) NOT NULL
  30. , nameSurname CHAR(47) NOT NULL
  31. , createDate DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
  32. , updateDate DATETIME DEFAULT '0000-00-00 00:00:00'
  33. , isClosed BOOL NOT NULL DEFAULT 0
  34. , closeDate DATETIME DEFAULT '0000-00-00 00:00:00'
  35. , ip CHAR(15) DEFAULT '000.000.000.000'
  36. , PRIMARY KEY (idTicket)
  37. , INDEX (idTicket)
  38. , CONSTRAINT FK_supportTickets_1 FOREIGN KEY (idTicket)
  39. REFERENCES supportPosts (idTicket)
  40. );
  41. CREATE UNIQUE INDEX supportTickets ON supportTickets (idAccount ASC);
  42.  
  43. CREATE TABLE accounts (
  44. idAccount SMALLINT(5) UNSIGNED NOT NULL AUTO_INCREMENT
  45. , idTicket INT UNSIGNED
  46. , idClient CHAR(6) NOT NULL
  47. , cEmail CHAR(40) NOT NULL
  48. , cName CHAR(18) NOT NULL
  49. , cSurname CHAR(28) NOT NULL
  50. , cPassword CHAR(32) NOT NULL
  51. , lastLogin DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
  52. , PRIMARY KEY (idAccount)
  53. , INDEX (idTicket)
  54. , CONSTRAINT FK_accounts_1 FOREIGN KEY (idTicket)
  55. REFERENCES supportTickets (idTicket)
  56. );
  57. CREATE UNIQUE INDEX accounts ON accounts (idTicket ASC, idClient ASC, cEmail ASC);



nie wiem czy dobrze stworzyłem relacje.
Chodziło mi o to, że w tabeli accounts są użytkownicy (klienci), którzy piszą sobie tickety (zapytania / problemy) supportTickets. Zaś następnie mogą być też odpowiedzi do ticketów supportPosts.

Proszę o wskazówki czy w miarę dobrze to wykonałem czy to jest totalna klapa, jeśli źle jest to zrobione to prosiłbym o pomoc w poprawieniu.

Pozdrawiam
Sedziwoj
Możesz opisać co ma dokładnie realizować ta baza danych. Bo napisałeś coś o klientach, ticket'ach, ale jak to ma działać nie opisałeś, a bez tego można tylko zgadywać.
Czyli opisowo (bez odwołań do tego co masz) napisz co ma to robić, kto uczestniczy, co może robić.
MitS
Oki smile.gif

więc zacznę od tego iż do tabeli accounts sam będę dodawał userów - to będą klienci firmy.
Klienci firmy gdy będą potrzebowali wykonania pewnej usługi przez firmę, zamist pisać do nas na maila to będą mogli napisać tzw. ticket'a na stronie (czyli prośbę o wykonanie czegoś, poprawinie błędów, lub inne zapytanie). Do tego będzie słóżyła tabela supportTickets czyli dany klient będzie mógł napisać wiele ticketów, zaś te tickety będą mogły należęć do jednego usera. Kolejną rzeczą jest odpowiadanie na tickety - tabela supportPosts - odpowiedź na tickety mogą pisać administratorzy (superUser) oraz autorzy danego ticketa. Odpowiedzi nie mogą być pisane przez danego usera 2 razy (lub więcej) pod rząd - czyli jak user napisze ticketa to najpierw musi odpowiedzieć na niego superUser dopiero po odpoiwedzi admina, user może napisać kolejną odpowiedź.

myślę że bardziej rozjaśniłem mój problem.
Pozdrawiam
Sedziwoj
To masz:
- ticket
- ticket_comment
- user
- firm_data
Ja bym coś w tym raczej stylu zrobił (nie chodzi o nazewnictwo).
ticket, ticket_comment mają referencje do user
user zawiera wszystkich użytkowników, w wyróżnieniem czy to admin, czy firma
firm_data zawiera dane które posiada firma, bo w tabeli user, są tylko podstawowe dane.

Nie blokował bym możliwości dodawania wielu uwag do ticket'a pod rząd, bo to może być potrzebne, bo mogą wychodzić rzeczy w trakcie itp.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.