projekt bazy danych + relacje Opcje

[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:

[SQL] pobierz, plaintext 
CREATE TABLE supportPosts (
       idTicket INT UNSIGNED NOT NULL
     , idPost SMALLINT(2) UNSIGNED NOT NULL
     , title CHAR(150) NOT NULL
     , content TEXT
     , idSuperUser CHAR(6)
     , superuserSeen BOOL NOT NULL DEFAULT 0
     , userSeen BOOL NOT NULL DEFAULT 0
     , addDate DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
     , PRIMARY KEY (idTicket)
);
CREATE INDEX supportPost ON supportPosts (idTicket ASC, idSuperUser ASC);
 
CREATE TABLE support (
       idSupport SMALLINT(2) UNSIGNED NOT NULL AUTO_INCREMENT
     , idSuperUser CHAR(6) NOT NULL
     , nameSurname CHAR(47) NOT NULL
     , email CHAR(40) NOT NULL
     , superUserPosition CHAR(30)
     , accessRights SMALLINT(1) UNSIGNED NOT NULL DEFAULT 1
     , PRIMARY KEY (idSupport)
);
CREATE UNIQUE INDEX support ON support (idSuperUser ASC, email ASC);
 
CREATE TABLE supportTickets (
       idTicket INT UNSIGNED NOT NULL
     , idAccount SMALLINT(5) UNSIGNED NOT NULL
     , title CHAR(150) NOT NULL
     , email CHAR(40) NOT NULL
     , nameSurname CHAR(47) NOT NULL
     , createDate DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
     , updateDate DATETIME DEFAULT '0000-00-00 00:00:00'
     , isClosed BOOL NOT NULL DEFAULT 0
     , closeDate DATETIME DEFAULT '0000-00-00 00:00:00'
     , ip CHAR(15) DEFAULT '000.000.000.000'
     , PRIMARY KEY (idTicket)
     , INDEX (idTicket)
     , CONSTRAINT FK_supportTickets_1 FOREIGN KEY (idTicket)
                  REFERENCES supportPosts (idTicket)
);
CREATE UNIQUE INDEX supportTickets ON supportTickets (idAccount ASC);
 
CREATE TABLE accounts (
       idAccount SMALLINT(5) UNSIGNED NOT NULL AUTO_INCREMENT
     , idTicket INT UNSIGNED
     , idClient CHAR(6) NOT NULL
     , cEmail CHAR(40) NOT NULL
     , cName CHAR(18) NOT NULL
     , cSurname CHAR(28) NOT NULL
     , cPassword CHAR(32) NOT NULL
     , lastLogin DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00'
     , PRIMARY KEY (idAccount)
     , INDEX (idTicket)
     , CONSTRAINT FK_accounts_1 FOREIGN KEY (idTicket)
                  REFERENCES supportTickets (idTicket)
);
CREATE UNIQUE INDEX accounts ON accounts (idTicket ASC, idClient ASC, cEmail ASC);
[SQL] pobierz, plaintext 

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

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.