Baza bez kluczy obcych

0

Witam
Z uwagi na to, że pracuje w niewielkiej firmie i spokoju w moim projekcie dołączyłem na chwilę do chłopaków co piszą jakieś dodatki do Comarcha. No, ale do rzeczy. Otóż wiele relacji w bazie mimo powiązań z innymi nie ma zadeklarowanych kluczy obcych. Przykładowo mamy powiązanie między tabelami, w dokumentacji mamy również wpis o związku na przykład jeden do wielu, ale nie ma tam żadnych kluczy obcych. W niektórych owszem i jest. Wzbudziło to moje zdziwienie, iż postanowiłem zapytać was ? Czy może to być spowodowane jakimiś względami wydajnościowymi ? Czy może to być zrobione dlatego, że w bazie dochodziło do wielu absurdalnych rzeczy ? Jest to dość konfigurowalny system "prawie ERP", wiec... Może odpowiedź jest naprawdę banalna, dlatego prosiłbym o wyrozumiałość, ale kto pyta nie błądzi.

Pozdrawiam

1

Jak baza jest duża i były robione częste aktualizacje struktury to pewnie dropowali tabele, backupujac wcześniej dane do innej tabeli po czym wstawiali je do tabeli macierzystej w całkowicie zmienionej formie. Wiadomo, że przy dropie tabeli powiązanej kluczami to byłby problem, a tak... pewnie nie chciało im się bawić w rozwiązywanie zależności kluczy obcych i zostawili same id'ki do tabel, po prostu. ;-) Pozakladali jeno same indeksy i już. Czy to dobrze? Zależy, od której strony patrzeć.

3
grzesiek51114 napisał(a):

Jak baza jest duża i były robione częste aktualizacje struktury to pewnie dropowali tabele, backupujac wcześniej dane do innej tabeli po czym wstawiali je do tabeli macierzystej w całkowicie zmienionej formie. Wiadomo, że przy dropie tabeli powiązanej kluczami to byłby problem, a tak... pewnie nie chciało im się bawić w rozwiązywanie zależności kluczy obcych i zostawili same id'ki do tabel, po prostu. ;-) Pozakladali jeno same indeksy i już. Czy to dobrze? Zależy, od której strony patrzeć.

Nie ma to nic wspólnego z tym co napisałeś. Ba! Nawet zmiana struktury bazy danych jest baardzo nieczęsta...
Wyjaśnienie jest prozaiczne; zaszłość. Kiedyś ERP XL nazywało się CDN XL i było pisane w Clarionie.
I m.in. stąd patent z zapisem daty nie w polu z typem DATE a INT, brak kluczy obcych i cała masa innych "ciekawostek" - wystarczy zajrzeć w dokumentację do bazy danych...

Czy to dobrze?
Nie, to fatalnie, ponieważ baza z siebie nie jest odporna na wprowadzanie błędnych danych.
Pewnie, można zrobić to przez aplikację - ale osobiście uważam, że podstawowa walidacja (not null, klucze obce, klucze unikalne, itp.) powinny być robione przez bazę danych.

0

Pracowałem już przy kilku projektach i żaden nie miał kluczy obcych. Integralność danych na tym poziomie zapewniała aplikacja a klucze obce tylko przeszkadzały w replikacji danych między urządzeniami.

0
MiL napisał(a):

Pracowałem już przy kilku projektach i żaden nie miał kluczy obcych. Integralność danych na tym poziomie zapewniała aplikacja

Aplikacja może zapewnić integralność na poziomie aplikacji, nie bazy.

klucze obce tylko przeszkadzały w replikacji danych między urządzeniami.

W jakiej technologii nie odkryto jeszcze guidów?

0

@Juhas tak z ciekawości jakie updejty masz na myśli pisząc, że klucze obce utrudniają ich pisanie? Moje bazy miała już dużo zmian w strukturze i jeszcze nie natrafiłem na przypadek aby update kolidował z jakimiś kluczami.

0

Update'y w sensie aktualizacje systemu.

2
Juhas napisał(a):

Update'y w sensie aktualizacje systemu.

No i?
Jak chcesz wprowadzić informacje, które nie spełniają kryterium integralności, to dobrze że klucz obcy na to nie pozwala.
W końcu do tego służy.

0
Juhas napisał(a):

Update'y w sensie aktualizacje systemu.
Ale to mnie nie przekonuje. U nas też takie rzeczy są i naprawdę nie widzę tutaj żadnych problemów....

0

aplikacja ktora rozwijamy, rowniez nie ma kluczy obcych. Po prostu relacyjnosc jest ustawiana na poziomie aplikacji. Jakby to zle nie brmialo, tak wlasnie jest i nawet tacy wielcy producenci jak HP stosuja te rozwiazanie w swoich produktach.

1
Vanilka napisał(a):

Jakby to zle nie brmialo, tak wlasnie jest i nawet tacy wielcy producenci jak HP stosuja te rozwiazanie w swoich produktach.

A robicie tak, bo?

Jakby to nie zabrzmiało, nawet w wielkich korporacja pracują lamusy...

0
Vanilka napisał(a):

aplikacja ktora rozwijamy, rowniez nie ma kluczy obcych. Po prostu relacyjnosc jest ustawiana na poziomie aplikacji.

Na czym polega "relacyjność na poziomie aplikacji"? Napisaliście aplikację opartą o algebrę relacji?
Czy może jesteście takimi ekspertami, że relacyjność i integralność to dla Was to samo?

2
Vanilka napisał(a):

Po prostu relacyjnosc jest ustawiana na poziomie aplikacji.
Jeśli chodzi Ci o utrzymywanie integralności podczas np. usuwania danych to rozwiązanie jest "mega suabe".

Klasycznie wyobraź sobie, że masz np. tabelę kontrahentów i wiadomo, że nie można usuwać kontrahenta jak ma wystawione jakieś faktury. W oddzielnej tabeli masz jeszcze jakieś zamówienia, czy jakieś pisma w innym module. Z czasem zrobi się z tego np. 20 tabel. Po paru latach dołożysz dodatkową. Teraz musisz pamiętać aby w module usuwającym kontrahentów dodać zmianę. Można, ale po co skoro można ustawić klucz zewnętrzny?

Jak rozumiem usuwanie np. pozycji dokumentu wraz z usunięciem główki też robicie ręcznie zamiast użyć kaskadowego usuwania? Jeśli tak to współczuję. Przy kilku tabelach może i da się, ale przy rozbudowanym systemie dla mnie zakrawa to na sadomasochizm :]

0
Mr.YaHooo napisał(a):

Jak rozumiem usuwanie np. pozycji dokumentu wraz z usunięciem główki też robicie ręcznie zamiast użyć kaskadowego usuwania? Jeśli tak to współczuję. Przy kilku tabelach może i da się, ale przy rozbudowanym systemie dla mnie zakrawa to na sadomasochizm :]

Zgoda, jeśli koduje się wszystko ręcznie.
Natomiast, co jeśli dostęp do DB jest przez warstwę ORM-like (zwłaszcza przy podejściu model-first, a więc baza to odzwierciedlenie modelu obiektowego), a klient nie rozmawia bezpośrednio z bazą danych, a z serwerem aplikacyjnym, który zapewnia dostęp do transakcyjnego modelu obiektowego?
No tu już bym się zastanowił, czy to właśnie nie najlepsze podejście ;-)
Inna sprawa, że FK w DB powinny być (chociażby bez kaskad, a więc tylko ograniczenia).

Równie dobrze można powiedzieć, że podejście "logika w bazie" przy rozbudowanym systemie to dopiero sadomasochizm :]

1

@wloochacz tak moje podejście jest w przypadku kodowania tego ręcznie. Odnośnie ORM-like nie wypowiem się, bo aż tak dużego doświadczenia nie mam. Jednak dalej obstawiałbym za utworzeniem chociażby podstawowych FK dla tego aby baza sama w sobie była spójna.

wloochacz napisał(a):

Równie dobrze można powiedzieć, że podejście "logika w bazie" przy rozbudowanym systemie to dopiero sadomasochizm :]
Bo jest. Upychanie dużej logiki jest trochę bez sensu. Nie mówię tu o logice typu wyliczenie jednej kolumny na podstawie innej. Ale znam przypadek gdzie za pomocą takich wyzwalaczy po 300-500 linii kodu SQL'owego były robione różne dziwne hocki-klocki. To już jest sadomasochizm. Dodatkowo tabele mają tak słabą strukturę, że aby wybrać najczęściej używane rzeczy i pokazać je userowi trzeba wywołać kolejną procedurę która ma 200 linijek kodu. Utrzymanie tego jest bardzo ciężkie. Ani tego nie przetestujesz ani nie zdebugujesz zbyt wygodnie. Dlatego jestem gorącym przeciwnikiem takich rozwiązań i sam używam minimalną ilość trigerów.

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