Aktywne Wpisy
ProstyHuop +27
#przegryw koledzy pisze chyba ostatni post na tym tagu bo się na nim nie odnajduje. Okazuje się ogułem że każdy tutaj ma jakiś kolegów na jakimś discordzie i se gadają (do tego wychodzi że są grupy huopskie podzielone i są wojny) a do tego wyszło że znają huopy tego scatmana a ja nie znam a do tego jeszcze wszystkiego każdy zaczął pisać że ja gej ja gej a ja nie
Fishwater +117
Zwalilem sobie po 15 dniach przerwy
Aktywne Znaleziska
Mam w bazie danych obiekt "płatnej subskrypcji". Za taką subskrypcję użytkownik może zapłacić sobie sam, albo może mu zapłacić organizacja. Zazwyczaj taki problem rozwiązywałem w taki (lub zbliżony) sposób:
table Subscription_payer (
subscriptionId int, -- subskrypcja, za którą zapłacono
payerType enum('user', 'organisation'), -- rodzaj płatnika
payerId int -- identyfikator płatnika w odpowiedniej tabeli
)
W bazach robionych przez innych również tak to rozwiązywano.
Problemem, przynajmniej w #mysql, jest to, że
payerIdnie może być kluczem obcym, bo nie wiadomo do której tabeli się odnosi.
Wymyśliłem dwa rozwiązania - rozbić tą tabelę na dwie (
subscription_payer_user,
subscription_payer_organisation), albo wprowadzić nadrzędny obiekt
Payer, który byłby źródłem kluczy obcych dla tabel
Useri
Organisation. Oba rozwiązania mają minusy - pierwsze nie gwarantuje unikalności, i pozwala na istnienie dwóch płatników dla jednej subskrypcji; drugie tworzy trochę za dużo bytów jak dla mnie - a podobnych problemów mogę jeszcze kilka mieć.
Coś jednak zrobić muszę - więc zapytuję mirków, którego rozwiązania by użyli i dlaczego. A może np. w #oracle lub #postgresql ma jakieś inne rozwiązania?
#bazydanych #sql
Nie znam bazy gdzie moglbys zrobic klucz obcy do wielu tabel z tej samej kolumny.
No i poztsaje jeszcze kwestia unikalnosci - co jesli userID i orgID beda takie same..?
W users masz pole type enumowy i apka wie z czym to jesc