Cześć, jako pracę inżynierską robię apkę dla uczniów szkoły do gry w bingo (wersja 3x9). Baza danych była robiona za pomocą phpmyadmin. Jak widać na załączonym obrazku po tym jak weszłam w widok 3 encje są nie powiązane z innymi i tu właśnie moje pytanie - Czy to jest nadal prawidłowe rozwiązanie? Czy w projekcie bazy danych mogą znajdować się niepowiązane tabele? A może macie pomysł jak z tego wybrnąć by było prawidłowo?
Dodam, że jestem osobą raczej początkującą.
Z góry dziękuję za pomoc:)
Niskiej rozdzielczości ten obrazek jest. ciężko się go czyta :(
AleksandraPHP napisał(a):
Jak widać na załączonym obrazku po tym jak weszłam w widok 3 encje są nie powiązane z innymi i tu właśnie moje pytanie - Czy to jest nadal prawidłowe rozwiązanie? Czy w projekcie bazy danych mogą znajdować się niepowiązane tabele?
Skąd pomysł że miałoby to być coś złego?
Np tabela migrations na 100% nie powinna być z niczym połączona.
Zwłaszcza że - pobieżnie ale w miarę się zorientowałem - te niezłączone są wybitnie administracyjnymi.
Mozna się kusić, ale to naprawdę doktorat, o relacji "reset passwords" do usera itd... ale to a) do niewielu rzeczy potrzebne b) uniemożliwiało by pełne kasowanie usera (a RODO ?)
jestem na "nie" na swój własny pomysł ;)
W kontekście, projektowania baz danych, nie ma nic złego w tym, że tablice nie posiadają powiązań.
To, że są nazywane relacyjnymi wcale nie wymusza na Tobie, tworzenia relacji do każdej tabeli.
Na poziomie logicznym, czystej logiki biznesowej, to mogłoby świadczyć o problemie, bo to znaczyłoby że działamy na dwóch rozłącznych domenach. W takim wypadku, dlaczego mielibyśmy je w jednym programie? Może staramy się zmieścić za dużo w jednym programie. Może też być tak, że jakieś powiązania są ukryte. Tak dzieje się np. z emailami w użytkownikach i resetach hasła. Dałoby się dość od jednego do drugiego, sprawdzając nie-klucz.
Tu jednak ewidentnie mamy tablice związane z jakąś biblioteką lub frameworkiem, więc jest to ok. Prawdopodobnie nie masz wpływu na to jak wyglądają ich wewnętrzne tablice i jak działają niech działają. W tym wpadku brak powiązania nie jest problemem.
Bardziej zwróciłbym uwagę na pola number-x-y . To wygląda jak mało przyjazne rozwiązanie. Rozważyłbym tablice o polach gra, x, y, wartość. Myślę że byłoby wydajniej i wygodniej w tworzeniu niektórych zapytań.
elwis napisał(a):
Na poziomie logicznym, czystej logiki biznesowej, to mogłoby świadczyć o problemie, bo to znaczyłoby że działamy na dwóch rozłącznych domenach. W takim wypadku, dlaczego mielibyśmy je w jednym programie?
No nie koniecznie musi to oznaczać. Relacja w bazie danych to tylko szczegół implementacyjny.
Błędem tutaj jest przekonanie że domena i baza mają być swoim mirrorem 1:1, a tak (poza bardzo prostymi aplikacjami) nigdy nie jest.
Mnie się wydaje, że relacja tickets jest tutaj większym problemem. Czemu ma tak dużo dziwnie nazwanych atrybutów number-x-y?
somekind napisał(a):
Mnie się wydaje, że relacja
ticketsjest tutaj większym problemem. Czemu ma tak dużo dziwnie nazwanych atrybutównumber-x-y?
W sumie racja, pewnie chodziło o to, żeby oznaczyć jakoś pozycje w tablicy 3x9.
Nigdy nie grałem w bingo więc nie wiem jakie są zasady.
Ale jeśli o to chodziło, to chyba lepiej stworzyć tablicę [field, x, y], gdzie field będzie przyjmował jakiegoś varchara w formie [x,y] dla rozróżnienia.