Pomoc przy zaprojektowaniu bazy

0

Poruszyłem tą kwestię w innym wątku, ale była trochę nie związana z pierwotnym temat.

Zastanawiam się, jak zaprojektować bazę danych, tak aby spełniała wszystkie najlepsze standardy.
Problem wygląda tak:
Mam tablice: Email, SMS, Fax, GG, Skype - wiadomość każdego typu w innej tablicy. Aby przykład był prosty niech ich struktury będą:
id int, test varchar(255). - Choć w rzeczywistości będą się jednak bardziej różnić.

Chcę stworzyć tablicę "Zadanie", która będzie miała pola: id, typ, sysWiadomosc.

Gdzie sysWiadomosc ma wskazywać na "id" w tablicy zależnej od pola typ.

Przykład:
Np. Typ = 1, to Email. Rekord w tablicy "Zadanie" (1,1,20) - to rekord o id=20 z tablicy Email.

Jak to rozwiązać? Nie mogę zastosować (chyba) klucza obcego - ponieważ, w takim wypadku jak wyżej, id=20 musi być w każdej z tablic (Email, SMS, Fax....).

0

dlaczego masz oddzielne tablice dla każdego typu wiadomości skoro logicznie są to takie same dane - wiadomości?

1

Czy nie możesz zunifikować tych pozostałych tabel (email, sms, fax, gg, skype)? Wydaje mi się że dane w nich powinny być podobne, tzn. wiadomość do wysłania, typ kanału i jakieś informacje pozwalające danym kanałem wysłać wiadomość.
Ewentualnie możesz w tabelach nadrzędnych mieć też ten dodatkowy id typ z check constraint i default value.
Czyli w tabeli Email miałbyś
TypId default 1 i check (1)
Id int autoincrement
PK na obu tych kolumnach
analogicznie w innych, tylko TypId musiałoby mieć inne wartości
A w tabeli Zadanie miałbyś klucz obcy też z dwóch kolumn, dzięki temu jako zadanie nie wstawisz FK, którego nie ma w odpowiedniej tabeli.

Ja raczej poszedłbym w unifikację tabel, niż takie czary-mary z kluczami.

0

Nie będą takie same. Napisałem "Choć w rzeczywistości będą się jednak bardziej różnić. " - Wiadomo, że struktura maila jest zupełnie inna niż wiadomości SMS.
Po drugie, w przypadku dojścia jakiegoś nowego typu, nie będę musiał zmieniać struktury tablicy, procedur czy funkcji, tylko dołożę kolejną i dodam ewentualne procedury.
No i baza jest chyba bardziej przejrzysta.

Można to jakoś połączyć? czy raczej nie praktykuje sie takich rozwiązań?

PS. Tylko w przypadku, gdy w bazie będzie 20002 smsów i 2 maile.. 20tys kolumn będzie miało puste takie pola jak CC, Bcc, isBodyHtml, czy co tam jeszcze ma e-mail a sms nie. Jest to dobre?

1

Lepiej wyjdź od drugiej strony vs twoja propozycja. Czyli tabela nadrzędna ze zunifikowanymi danymi wiadomości i określeniem typu kanału oraz tabele podrzędne precyzujące informacje dla kanału, czyli np. dla email ishtml, cc, bcc, ...
Dzięki temu masz klucz główny na tabeli nadrzędnej jako np. int autoincrement oraz FK w tabelach podrzędnych też jako int bez żadnych kombinacji.
Po stronie kodu składasz obiekt wiadomości odpowiedniego typu i wykonujesz wyślij (polimorfizm i wzorzec polecenia oraz wzrorzec metoda wytwórcza lub budowniczy będą pomocne).

Należy zadać sobie jeszcze pytanie czy treść wiadomości to zawsze tekst, czy również inny rodzaj danych, np. fax, email - obrazek, skype - dźwięk, email może także zawierać różne załączniki.
Jeśli treść może mieć różny rodzaj pewnie i na to przydałyby się podrzędne tabele składujące odpowiednie informacje: dane tekstowe, binarne, ścieżka do pliku na dysku, ...

0

Dzięki wielkie za pomoc.
Poszedłem jednak w strone jednej tabeli. W końcu, nie będą AŻ tak się różnić.

Wspomniałeś też o wzorcach. Miałeś na myśli późniejszą implementacje po stronie programu? Już chyba gdzieś o tym pisałem, ale zastosuję wzorzec fabryki. Tj.:
Fabryka wiadomość, i objekty: Email, Sms itd itd... każdy obiekt będzie miał te same własności: m.in: Wyślij:)
Mniej więcej tak:

  1. Fabryka pobierze ileś wiadomości z bazy do pętli
  2. W pętli, w zależności od typu wiadomości utworzy odpowiedni obiekt.
  3. obiekt.Wyslij();

I w sumie tyle.

0

Wg mnie raczej zastosujesz metodę wytwórczą, ale można to nazwać fabryką, zasada jest podobna.

0

Aha, no przyznam, że do końca nie opanowałem wszystkich tych wzorców (szczególnie dopasowanie danego wzorca do jego nazwy), więc możliwe, że coś pomieszałem.

Jeszcze raz dzięki za pomoc.

1 użytkowników online, w tym zalogowanych: 0, gości: 1