Forum Debian Users Gang

Huk · 2013-10-03 12:58:52

Witam.

Szukam na necie ale nigdzie nie jestem w stanie znaleźć jednoznacznej odpowiedzi.

Tworząc bazę mam tabelę z adresami (nic nadzwyczajnego: Id, KodPocztowy, Miasto, Ulica, NumerDomu/Lokalu). Mam też tabelę z użytkownikiem który posiada dwa rodzaje adresów: jeden korespondencyjny, oraz dostępności (dostępny od 1 do 15 stycznia w Pcimiu dolnym, od 15 do 31 w Warszawie itd) których może być nieskończona liczba. Jeszcze kilka innych tabel będzie musiało mieć podobną strukturę... w tym miejscu pytanie:

Czy jest jakieś lepsze rozwiązanie aniżeli dodawanie ogromnej ilości kluczy obcych do tabeli Address ? Myślałem o wykorzystaniu wielu tabel adresowych, ale to wydaje się tylko komplikować sprawę (o niezgodności z DRY nie wspominając).

Z góry dzięki za info.

Pozdrawiam.

kamikaze · 2013-10-03 13:14:58

O jakich kluczach obcych mówisz? Ja bym zrobił może tak. Tabele: AdresKorespondencyjny, AdresDostepnosci. W tabeli użytkowników klucz obcy adresKorespId jeśli każdy user ma jeden i tabela AdresDostepnosciUser(adresDostId, userId).

djjanek · 2013-10-03 14:34:19

z tego co rozumiem adresy i tak nie będą sie powtarzac zatem nie mam sensu dawac im osobnych tabeli.

Ja bym zrobił tak:

USERS:
id_users
.....

ADRESS:
id_address
users_id
ulica
miasto
....
OD
DO

Połącznie jedne do wielu
jeden user może mieć wiele adresów.

Huk · 2013-10-03 15:05:29

@kamikaze:

Zakładając że kilka tabel będzie mogło mieć więcej niż jeden adres, to dla każdej trzeba w tabeli adres dać klucz obcy na id tej tabeli - stąd takie coś wydaje się mało elastyczne. Całe pytanie właśnie w tym czy lepiej mieć tabelę w stylu:

Kod:

Adress
{
ID,
Kod,
Ulica,
Numer,
UserID,
KolejnyObcyID,
KolejnyObcyID
itd
}

i dopisywać kolejny klucz obcy za każdym razem kiedy coś będzie go potrzebować czy zrobić tak jak podałeś - kilka tabel adresowych, mnożąc tą samą strukturę razy ilość tabel wykorzystujących...

@djjanek:

Tak obecnie jest, pytanie jak wyżej - czy w przypadku konieczności dodania większej ilości kluczy obcych które będą musiały być Null'ami ( realnie zakładam że adres może być zależny tylko od jednego klucza) nie wpłynie to negatywnie na wydajność?

Czyżby to było jedno z tych rozwiązań w którym zawsze trzeba coś poświęcić?

BiExi · 2013-10-03 21:01:41

Huk Trochę ogólnie opisałeś problem

ale jeśli chodzi o łączenie tego typu informacji to stosuje się tabele łączące. Dziala to tak ze masz tabele w ktorej masz 2 klucze obce jeden z tabeli z miskami kolejny z tabeli z adresami

Huk · 2013-10-04 07:57:50

@BiExi:

Dzięki za info, faktycznie w sumie ten sam mechanizm co w relacji wiele do wielu dałby tutaj radę - pytanie jak się ma wydajność z użyciem tabeli pośredniej do pojedynczej tabeli z wieloma kluczami obcymi... robił ktoś może porównanie?

Nie chciałbym żeby się potem okazało że SQL jest ładny ale wolny jak żółw ;]

Pozdrawiam.

BiExi · 2013-10-05 14:24:33

Generalnie nie znam struktury projektowanego przez Ciebie systemu, wybór metody zależy właśnie od tego jak ma ten system jest zbudowany.
Pierwsze pytanie jak dużo danych będziesz w nim przechowywał myślę że kilka kilkanaście tysięcy powiązań powinno dać radę.
Dużo też zależy od tego w jakiej technologi interfejs do swojego systemu będziesz tworzył.
Kolejna sprawa to wybór silnika baz danych
Jak często będzie się zmieniać zawartość bazy tutaj można wykorzystać różne metody cachowania aby poprawić wydajność całości
, generalnie bazy są zazwyczaj bardzo elastyczne zawsze można je przeportować na inne rozwiązania więc co Ci zostaje experymentowanie :)

Co jeszcze mogę Ci polecić to wybierz sobie wszystko co będziesz robił w tym systemie np porównywanie danych jakieś raporty i zastanów się jak zaprojektować bazę by któraś z operacji jej nie zarżnęła.

adasMrowa · 2013-11-22 18:44:41

Może wystarczy zastosować pole rodzaj adresu i mieć jedną tabelę z adresami i dodatkowo tabelę słownikową dla typu adresu, jeżeli ilość typów adresu miała by być rozszerzalna.

Forum Debian Users Gang

Ogłoszenie

#1 2013-10-03 12:58:52

Huk - Smoleńsk BULWA!

SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#2 2013-10-03 13:14:58

kamikaze - Administrator

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#3 2013-10-03 14:34:19

djjanek - Użytkownik

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#4 2013-10-03 15:05:29

Huk - Smoleńsk BULWA!

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

Kod:

#5 2013-10-03 21:01:41

BiExi - matka przelozona

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#6 2013-10-04 07:57:50

Huk - Smoleńsk BULWA!

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#7 2013-10-05 14:24:33

BiExi - matka przelozona

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

#8 2013-11-22 18:44:41

adasMrowa - Nowy użytkownik

Re: SQL - jedna tabela adresowa z wieloma kluczami obcymi - da się lepiej?

Stopka forum