Temat: Diagram E/R w UML?

ROMAN WILK:

Kamil Stawiarski:
Silniki relacyjnych baz danych są związane z więzami integralności (constraint'ami) i bez względu czy masz OLAP czy OLTP to musisz się pogodzić z faktem, że są one tam uparcie obecne bo silniki RDBMS powstały z myślą o ich wykorzystaniu. Bez więzów integralności optymalizator SQL nie jest w stanie podejmować decyzji o transformacji SQL przy użyciu złączeń ze zmaterializowanymi widokami, nie potrafi też wykonywać takich operacji jak Join Elimination ...

Jeśli już decydujemy się na jakiś silnik RDBMS to róbmy to dobrze.

To na pewno w dużej mierze dotyczy Oracle. Natomiast RDBMS to nie tylko Oracle, a ze względu na coraz większą moc obliczeniową pozostałe bazy godnią w wydajności Oracle. Zapytania SQL można optymalizować, wymuszać korzystanie z określonych indeksów itd. Poza tym, to że nie nałożono więzów na poszczególne pola w tabelach, nie oznacza że nie założono indeksów tak, aby baza dziłała jak najwydajniej. Przecież zajmujesz się zwiększeniem wydajności baz danych to pewnie o tym doskonale wiesz ?

Masz rację. Jednak to co napisałem jest charakterystyczne nie tylko dla Oracle - optymalizator kosztowy PostgreSQL bardzo mocno goni Oracle, chociaż mu jeszcze brakuje. Ale wszystkie optymalizatory kosztowe RDBMS w dużej mierze bazują na wiedzy o danych - inteligentne przetwarzanie zapytań wymaga dostarczenia odpowiednich statystyk a wśród nich informacji o więzach integralności. Oracle faktycznie przoduje w tej praktyce ale jedyny nie jest.

Ale głównie chodziło mi o to, że normalizacja jednak jest z definicji związana z więzami integralności a przy okazji stały się one również istotnym źródłem informacji dla inteligentnego budowania planów wykonania zapytań przez optymalizator.

Temat: Diagram E/R w UML?

A można (podobno): http://modeling-languages.com/uml2db-full-code-generat...

jak się stworzy tak zwany "anemiczny model dziedziny" czyli popełni antywzorzec obiektowy :) i doda niestandardowe opcje do notacji UML (diagram klas)
http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

Schemat bazy generalnie jest 'anemiczny'. A ww. usługa generuje tylko to.

Temat: Diagram E/R w UML?

Postać normalna dotyczy organizacji danych w tabeli i ma niewiele wspólnego z 'kluczami obcymi'.

Chciałem już sobie darować ten temat ale tutaj muszę się wtrącić: cytując za autorem normalizacji i postulatów baz relacyjnych:

"Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications."

Wciąż twierdzę, że owe 'constraints' dotyczą organizacji danych w tabeli.

Silniki relacyjnych baz danych są związane z więzami integralności (constraint'ami) i bez względu czy masz OLAP czy OLTP to musisz się pogodzić z faktem, że są one tam uparcie
obecne bo silniki RDBMS powstały z myślą o ich wykorzystaniu.

Proszę o to samo w jednej linijce i bez marketingu.:>
"Można to zrobić, więc trzeba to zrobić" ?

Bez więzów integralności optymalizator SQL nie jest w stanie podejmować decyzji o transformacji SQL przy użyciu złączeń ze zmaterializowanymi widokami, nie potrafi też wykonywać takich operacji jak Join Elimination ...

o jakich bazach mówimy ?

Jeśli już decydujemy się na jakiś silnik RDBMS to róbmy to dobrze.

a ja myślę na odwrót tzn: jeśli chcemy coś zrobić dobrze to ...

Temat: Diagram E/R w UML?

Jakub Wojt:

Postać normalna dotyczy organizacji danych w tabeli i ma niewiele wspólnego z 'kluczami obcymi'.

Chciałem już sobie darować ten temat ale tutaj muszę się wtrącić: cytując za autorem normalizacji i postulatów baz relacyjnych:

"Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications."

Wciąż twierdzę, że owe 'constraints' dotyczą organizacji danych w tabeli.

Wprawdzie Codd mówił o relacji klucz główny-klucz obcy między poszczególnymi tabelami ale może faktycznie Ty wiesz lepiej i nie ma to nic wspólnego z normalizacją. Proponuję, żebyś napisał do wszystkich autorów opracowań na ten temat i wytknął im ten karygodny błąd.

Silniki relacyjnych baz danych są związane z więzami integralności (constraint'ami) i bez względu czy masz OLAP czy OLTP to musisz się pogodzić z faktem, że są one tam uparcie
obecne bo silniki RDBMS powstały z myślą o ich wykorzystaniu.

Proszę o to samo w jednej linijce i bez marketingu.:>
"Można to zrobić, więc trzeba to zrobić" ?

Jeśli wsiadasz do samochodu i zapinasz do niego wołu to na ch** Ci ten samochód?

Bez więzów integralności optymalizator SQL nie jest w stanie podejmować decyzji o transformacji SQL przy użyciu złączeń ze zmaterializowanymi widokami, nie potrafi też wykonywać takich operacji jak Join Elimination ...

o jakich bazach mówimy ?

O wszystkich silnikach relacyjnych, które zaimplementowały mechanizmy optymalizatorów kosztowych.

Jeśli już decydujemy się na jakiś silnik RDBMS to róbmy to dobrze.

a ja myślę na odwrót tzn: jeśli chcemy coś zrobić dobrze to ...

Po raz kolejny: nie uważam, że RDBMS jest remedium na wszystko. Twierdzę jednak, że jak się już ktoś na to zdecyduje to niech korzysta z jej mechanizmów i niech robi to zgodnie ze sztuką - a jak nie, to niech sobie używa plików płaskich bo po kiego grzyba mu wtedy RDBMS?Kamil Stawiarski edytował(a) ten post dnia 07.11.11 o godzinie 21:19

Temat: Diagram E/R w UML?

Po raz kolejny: nie uważam, że RDBMS jest remedium na wszystko. Twierdzę jednak, że jak się już ktoś na to zdecyduje to niech korzysta z jej mechanizmów i niech robi to zgodnie ze sztuką - a jak nie, to niech sobie używa plików płaskich bo po kiego grzyba mu wtedy RDBMS?

parafrazując powyższe: jeżeli ktoś tworzy system metodami obiektowymi to po kiego dodawać relacyjny system utrwalania ;)

Temat: Diagram E/R w UML?

Jarek Żeliński:

Po raz kolejny: nie uważam, że RDBMS jest remedium na wszystko. Twierdzę jednak, że jak się już ktoś na to zdecyduje to niech korzysta z jej mechanizmów i niech robi to zgodnie ze sztuką - a jak nie, to niech sobie używa plików płaskich bo po kiego grzyba mu wtedy RDBMS?

parafrazując powyższe: jeżeli ktoś tworzy system metodami obiektowymi to po kiego dodawać relacyjny system utrwalania ;)

Wszystko zależy od potrzeb i nie opędzisz całego świata jednym rozwiązaniem.

Ale dane jakoś składować trzeba. Można w XML'u (ale silniki baz danych i na to mają implementację, bo weszło do standardu). Można w plikach płaskich a jak się uprzeć to można i na kartach perforowanych... Wszystko można, pod warunkiem że jest to uzasadnione. A silniki RDBMS są i póki co mają się wyśmienicie - licencje idą dobrze, szkolenia jak świeże bułeczki a zapotrzebowanie na optymalizację rośnie, bo zdecydowana większość systemów pojawiających się na rynku korzysta jednak pod spodem z jakiegoś silnika relacyjnych baz danych.

Temat: Diagram E/R w UML?

A silniki RDBMS są i póki co mają się wyśmienicie - licencje idą dobrze, szkolenia jak świeże bułeczki a zapotrzebowanie na optymalizację rośnie, bo zdecydowana większość systemów pojawiających się na rynku korzysta jednak pod spodem z jakiegoś silnika relacyjnych baz danych.

Bo niejeden służy do zarządzania hurtowniami danych (proste nierelacyjne modele) i zestawami prostych luźno lub w ogóle powiązanych tablic jako repozytoria systemów obiektowych :). Ostatnio czytałem opis nowego Dynamic AX: system zaprojektowany (przeprojektowany) obiektowo, obiekty biznesowe to proste mapowania klasa-tablica, i owszem MS SQL Server jako narzędzie utrwalania...

nie ma się co przekonywać bo oba modele (relacyjny i nierelacyjny) są na rynku obecne... a są implementowane na tych samych motorach serwerowych :) i udowadnianie wyższości jednego nad drugim to chyba kiepski pomysł...Jarek Żeliński edytował(a) ten post dnia 07.11.11 o godzinie 21:51

Temat: Diagram E/R w UML?

Jarek Żeliński:

Bo niejeden służy do zarządzania hurtowniami danych (proste nierelacyjne modele)

Schematy hurtowni danych to też tak na prawdę relacyjne modele, tylko że zdenormalizowane (tak jak w schemacie gwiazdy) ale fizyczne relacje między faktem a wymiarami nadal są tam obecne.

nie ma się co przekonywać bo oba modele (relacyjny i nierelacyjny) są na rynku obecne... a są implementowane na tych samych motorach serwerowych :) i udowadnianie wyższości jednego nad drugim to chyba kiepski pomysł...

Tu się zgadzam. To tak jak dyskusja o wyższości linuxa nad windowsem .... wszyscy przecież wiedzą, że linux jest lepszy :D :PKamil Stawiarski edytował(a) ten post dnia 07.11.11 o godzinie 22:09

Temat: Diagram E/R w UML?

Jarek Żeliński:
bo moją rolą jest zaprojektować logikę, dostawca ją implementuje :), no to nieporozumienie wyjaśnione :)

I korzysta z mechanizmu transakcji, który dostarcza mu ktoś inny, bo porywanie się na pisanie takiego mechanizmu to grubsza sprawa. Tyle chciałem powiedzieć.

tylko, że ta wydajność straciła wartość rynkową... więc na rynku przegrał..

Owszem, wydajność przez koszt w czasie rośnie i długo jeszcze nie przestanie rosnąć :).

nigdzie nie napisałem, że programuję ale stale mam do czynienia oprogramowaniem dostarczonym i zapewniam, że świat jest bogaty w rozwiązania i, że się powtórzę, nie ma rozwiązań jedynie słusznych.

Nie kierowałem tego personalnie. Po prostu obrazek był niepełny.

Temat: Diagram E/R w UML?

Jakub Wojt:
Ale to i tak sprawdza tester funk. biznesowej. Różnica będzie taka, że zamiast danych niezgodnych z protokołem dostanie 'error'.

Nie wyobrażam sobie, żeby taki test obejmował wszystkie przypadki... A raz założony constraint przetestuje za Ciebie wszystko i do tego nie pozwoli na śmiecie w przyszłości.

No chyba, że chcesz to testować zapytaniami. Ale ty jesteś zwolennikiem prostych rozwiązań. A napisać zapytanie to wychodzi dłużej niż constraint...

Można ale w zależności od produktu te mechanizmy są inaczej realizowane.

To nie ma znaczenia. Ważne, że w tak samo łatwy sposób możesz osiągnąć ten sam skutek na dowolnym rdbms. I do tego są narzędzia, które model pomogą Ci utrzymać w oderwaniu od faktycznie wybranego silnika.

I tak na prawdę guzik mnie obchodzi reszta.

Hehe. A potem przychodzi po Tobie taki gość jak ja i zaczyna importować te dane do hd i się zaczyna...

I to świadczy tylko o tym, że nie powinno się 'omijać' systemu podczas importu danych.

Nie rozumiem. Nie omijanie systemu sprawi, że śmieci znikną w źródle?

A skąd wiesz, że nie pomyliłeś się w tej linijce kodu ?
Taką argumentację może rozszerzyć na cały system...

Nie rób jaj... Bo zaraz ja sobie pomyślę, że nie wiesz o czym piszesz...

Uznaję to za 'nie wiem'.

Hehe. Uznaj sobie za co chcesz ;-) Jak zrobię błąd w kodzie constraintu to najprawdopodobniej ujawni się on w momencie zakładania, albo przy pierwszych insertach. Więc jeszcze w czasie dewelopmentu. Twój błąd pojawi się najprawdopodobniej dopiero na testach, albo (co gorsza) w czasie użytkowania...

Skoro wielu twierdzi, że można sobie pozwolić na zdenormalizowany model danych (z czym się zgadzam),

Postać normalna dotyczy organizacji danych w tabeli i ma niewiele wspólnego z 'kluczami obcymi'.

Zgadza się. Constrainty stosuje się również z powodzeniem na modelach zdenormalizowanych, bo tam też pełnią pożyteczną rolę. Zawsze kontrolują spójność danych. A ty chcesz z nich z jakiegoś powodu rezygnować.

Wyjaśnij mi. Po co w takim razie w ogóle stosować rdbms jak kontener na dane? Są jakieś zalety? Jeżeli tak, to jakie?

Są stabilne, jest do nich masa narzędzi, SQL zna większość programistów ... :)

Plik tekstowy. Jest stabilny. Jest masa edytorów. Pisany tekst zna większość ludzi...

Jaka zatem jest wyższość rdbms nad plikiem tekstowym?

Twoja kolej :)

Hehe. Już trochę zmęczony jestem ;-)

Temat: Diagram E/R w UML?

Jakub Wojt:
Rozmowa dotyczy potencjalnych wad/zalet fizycznego mechanizmu kluczy obcych a nie modelowania danych.

Przeczytaj całą wypowiedź... Odpowiednie modelowanie => mniej roboty chałupniczej.

Praktycznie każde na podstawie "kresek" wygeneruje Ci odpowiednie skrypty na co popularniejsze bazy danych. Jak używasz jakiejś egzotyki, to powstaje kwestia obróbki w dowolnym edytorze tekstu.
W przypadku optymistycznym (używasz narzędzi ER) w fazie projektowania roboty się nie dokłada.

Ale to tylko pod warunkiem, że nie można automatycznie generować schematu bazy na podstawie modelu domeny w UML (inaczej to dodatkowa robota).

A można (podobno): http://modeling-languages.com/uml2db-full-code-generat...

Jeśli jakość tego narzędzia uważasz za wystarczającą, to proszę bardzo używaj. Dobrze by było, gdyby narysowało diagram ER.

w negatywnym dojdzie do rękoczynów ? :)

Jak najbardziej ;).

Zakładasz, że 'zakładanie kluczy obcych' jest czynnością, przy której ludzie się nie mylą.

Nic takiego nie zakładam. Wiem, że takie błędy wychodzą bardzo szybko, jeśli nie najszybciej.

Jak przetestujesz poprawność i kompletność zbioru kluczy obcych ?

Ja nie mam zamiaru nic testować. Baza to wykryje, przy pierwszej lepszej serii insertów. Jak ktoś się machnie i zaznaczy więzy pomiędzy id klienta z tabeli z fakturami i id faktury z tabeli z pozycjami faktury, to jak myślisz który insert do pozycji faktury wyrzuci Ci błąd?

A błędy i tak zostaną wykryte podczas testowania funkcjonalności biznesowej.

Chyba znowu rozmowa dotyczy dwóch różnych tematów ...

Aha, a skąd te błędy z którymi mi się przyszło zetknąć? Skąd to parcie na prędkie domykanie testów? Skąd to zamiatanie pod dywan mniej krytycznych błędów?

Hm .. czy na systemie produkcyjnym (aplikacja została wdrożona i przetestowana) są potrzebne klucze obce ?

Tak. KS chyba już to powtórzył kilka razy.
Jak często robiony jest insert/update/delete, a jak często robiony jest select? Na wydajności pierwszych operacji stracisz, a na wydajności drugich zyskasz. Systemy OLTP mają to do siebie, że znakomita większość operacji odbywa się na pojedynczych rekordach. To co KS stara się wytłumaczyć przy okazji optymalizatora kosztowego, to jest to, że istnienie więzów jest cenną informacją dla optymalizatora. Większość select'ów w OLTP działa, a właściwie powinno działać, na zasadzie skanowania indeksu na wybranej przez optymalizator tabeli i na podstawie zwróconych rekordów powinno się odbywać skanowanie indeksu na dalszych tabelach, które uczestniczą w złączeniu. Wystarczy zerknąć na hasło nested loops w google i będzie wiadomo o co chodzi.
Jest kilka innych grzechów, które mocno bolą. Na przykład dynamiczne "sklejanie" poleceń sql zamiast używania "bind variables", czy brak partycjonowania. Oczywiście dużo znaczy odpowiedni tuning bazy pod aplikację, ale to już coś dla administratorów, a nie programistów.

Temat: Diagram E/R w UML?

Ale to i tak sprawdza tester funk. biznesowej. Różnica będzie taka, że zamiast danych niezgodnych z protokołem dostanie 'error'.

Nie wyobrażam sobie, żeby taki test obejmował wszystkie przypadki... A raz założony constraint przetestuje za Ciebie wszystko i do tego nie pozwoli na śmiecie w przyszłości.

proponuję mieć świadomość, że:
- proste ograniczenia blokują wyłącznie operacje niedozwolone
- logika biznesowa to nie tylko proste ograniczenia ale też "sam sposób wyliczenia czegoś"

Jeżeli ktoś uważa, że proste ograniczenia w bazie zastępują testowanie to tak jak by powiedzieć, że kontroler ortografii w edytora tekstu zastępuje recenzentów. Nie zapominajmy, ze można bełkotać, a nawet kłamać, nie popełniając błędów ortograficznych czy gramatycznych.

I to świadczy tylko o tym, że nie powinno się 'omijać' systemu podczas importu danych.

Nie rozumiem. Nie omijanie systemu sprawi, że śmieci znikną w źródle?

sprawi, że dane wyeksportowane będą świadomie z użyciem logiki oprogramowania a nie tylko prostej zgodności tabel bo to nie to samo...

trochę ta dyskusja zmierza w stronę próby udowodnienia tezy, że edytor tekstu wraz z dobrymi regułami kontroli składni i ortografii sam z siebie czyni pisane nim teksty mądre i ciekawe. Jest dokładnie odwrotnie...

Mogę napisać "coś mądrego" notatnikiem, troszkę wolniej i sam muszę sprawdzić błędy, ale sam fakt posiadania wypasionego edytora tekstowego nie uczyni tego tekstu nawet o milimetr mądrzejszym... sami wybieramy sposób pracy mając ograniczone zasoby ...

Temat: Diagram E/R w UML?

Jarek Żeliński:
proponuję mieć świadomość, że:
- proste ograniczenia blokują wyłącznie operacje niedozwolone
- logika biznesowa to nie tylko proste ograniczenia ale też "sam sposób wyliczenia czegoś"

Nikt nie broni implementować logikę w dowolny inny sposób. Ale więzy integralności w rdbms to jest podstawa wszelkich podstaw. Bo nie ma nic gorszego niż rozspójniona baza.

Jeżeli ktoś uważa, że proste ograniczenia w bazie zastępują testowanie to tak jak by powiedzieć, że kontroler ortografii w edytora tekstu zastępuje recenzentów. Nie zapominajmy, ze można bełkotać, a nawet kłamać, nie popełniając błędów ortograficznych czy gramatycznych.

Testy są potrzebny. Ale po co przeprowadzać testy niepotrzebne?

Mogę napisać "coś mądrego" notatnikiem, troszkę wolniej i sam muszę sprawdzić błędy, ale sam fakt posiadania wypasionego edytora tekstowego nie uczyni tego tekstu nawet o milimetr mądrzejszym... sami wybieramy sposób pracy mając ograniczone zasoby ...

Ale wypasiony edytor może Ci usprawnić pracę, tylko się musisz z niego nauczyć poprawnie korzystać (Zakładam, że jest Ci potrzebny, bo po coś go kupiłeś). I tylko i wyłącznie o to chodzi.

Proste ograniczenie mogą sprawić, że nie będziesz miał śmieci w danych. Są łatwe w zakładaniu i utrzymaniu. Jak masz rdbms to nie rozumiem niechęci ich do ich stosowania. Takie nie, bo nie...Krzysztof Bokiej edytował(a) ten post dnia 08.11.11 o godzinie 08:33

Temat: Diagram E/R w UML?

Mam wrażenie, że każdy wyraził swój pogląd, zaczynamy się chyba powtarzać. Ja nie jestem technokratą. Wiem też, że w projektach siano gra rolę bo wbrew pozorom jest żadną sztuką postawić system za 100mln. sztuka jest zrobić coś za 1/10 tej kwoty bo to zmusza do pewnych rezygnacji.

Osobiście stoję na stanowisku, że poczytne teksty publikowane w dobrej prasie, przynoszące jej nowych czytelników, są dziełem dziennikarzy a nie ich komputerów i edytorów tekstów, w redakcjach siedzą korektorzy a wielu dziennikarzy potrafi napisać świetny tekst w notatniku. Trudno będzie mnie jednak przekonać, że jakakolwiek technologia zastąpi tu człowieka, w szczególności korektora. I jeżeli jestem w stanie zrezygnować z "constraintów" tak nigdy nie zrezygnuje z testerów i planowania testów.

Pozostawiam czytelnikom i projektantom wnioski a wielu zazdroszczę komfortu pod tytułem "siano nie gra roli" oraz projektów "T&M"...

Temat: Diagram E/R w UML?

Jarek Żeliński:

Ale to i tak sprawdza tester funk. biznesowej. Różnica będzie taka, że zamiast danych niezgodnych z protokołem dostanie 'error'.

Nie wyobrażam sobie, żeby taki test obejmował wszystkie przypadki... A raz założony constraint przetestuje za Ciebie wszystko i do tego nie pozwoli na śmiecie w przyszłości.

proponuję mieć świadomość, że:
- proste ograniczenia blokują wyłącznie operacje niedozwolone
- logika biznesowa to nie tylko proste ograniczenia ale też "sam sposób wyliczenia czegoś"

Jeżeli ktoś uważa, że proste ograniczenia w bazie zastępują testowanie to tak jak by powiedzieć, że kontroler ortografii w edytora tekstu zastępuje recenzentów. Nie zapominajmy, ze można bełkotać, a nawet kłamać, nie popełniając błędów ortograficznych czy gramatycznych.

I to świadczy tylko o tym, że nie powinno się 'omijać' systemu podczas importu danych.

Nie rozumiem. Nie omijanie systemu sprawi, że śmieci znikną w źródle?

sprawi, że dane wyeksportowane będą świadomie z użyciem logiki oprogramowania a nie tylko prostej zgodności tabel bo to nie to samo...

trochę ta dyskusja zmierza w stronę próby udowodnienia tezy, że edytor tekstu wraz z dobrymi regułami kontroli składni i ortografii sam z siebie czyni pisane nim teksty mądre i ciekawe. Jest dokładnie odwrotnie...

Mogę napisać "coś mądrego" notatnikiem, troszkę wolniej i sam muszę sprawdzić błędy, ale sam fakt posiadania wypasionego edytora tekstowego nie uczyni tego tekstu nawet o milimetr mądrzejszym... sami wybieramy sposób pracy mając ograniczone zasoby ...

Świetne porównanie! Ja wolę czytać teksty zgodne z ortografią i gramatyką jakiegoś języka. Patrząc na zalety i wady korzystania z edytora i notatnika nie mam pojęcia, czemu komuś może zależeć na pisaniu w notatniku. Nie wiem również, czemu ktoś twierdzi, że to daje takie same efekty w dziedzinie jakości ortografii i gramatyki. Zróbcie niedowiarkowie eksperyment i skopiujcie z notatnika do edytora, czyli na jakiejś bazie bez więzów je załóżcie. Sprawdźcie ile podświetla na czerwono.

Co do testów to jakieś piramidalne nieporozumienie. Więzy stanowią test spójności danych, a nie test funkcjonalności. Tyle i nic więcej!

Temat: Diagram E/R w UML?

Świetne porównanie! Ja wolę czytać teksty zgodne z ortografią i gramatyką jakiegoś języka.

bezbłędny bełkot także?

Patrząc na zalety i wady korzystania z edytora i notatnika nie mam pojęcia, czemu komuś może zależeć na pisaniu w notatniku.

możliwe, że potrzebny jest sensowny tekst a nie ma dodatkowego budżetu na worda...

Nie wiem również, czemu ktoś twierdzi, że to daje takie same efekty w dziedzinie jakości ortografii i gramatyki.

znaczy się, że co - nie da się pisać bez błędów piórem na papierze?

Zróbcie niedowiarkowie eksperyment i skopiujcie z notatnika do edytora, czyli na jakiejś bazie bez więzów je załóżcie. Sprawdźcie ile podświetla na czerwono.

to zależy od autora tekstu :)

Co do testów to jakieś piramidalne nieporozumienie. Więzy stanowią test spójności danych, a nie test funkcjonalności. Tyle i nic więcej!

spójność danych to pojęcie rodem z baz relacyjnych... jakie "więzy" na bazę i spójność danych nałożysz w sytuacji gdy masz dwa systemy od dwóch producentów a w obu są dane o kontrahentach?

Ciśnie mi się na usta, że zabawa w system gdzie wszystkie dane są fajne i w jednej bazie relacyjnej to pikuś... se nieco bardziej wymagające środowiska... i warto o tym pamiętaćJarek Żeliński edytował(a) ten post dnia 08.11.11 o godzinie 09:47

Temat: Diagram E/R w UML?

Wciąż twierdzę, że owe 'constraints' dotyczą organizacji danych w tabeli.

Wprawdzie Codd mówił o relacji klucz główny-klucz obcy między poszczególnymi tabelami ale może faktycznie Ty wiesz lepiej i nie ma to nic wspólnego z normalizacją. Proponuję, żebyś napisał do wszystkich autorów opracowań na ten temat i wytknął im ten karygodny błąd.

To może podsumuję:
Znormalizowana baza danych to taka w której każda tabela przyjmuje jakąś postać normalną. Brak założonych kluczy obcych nie oznacza, że baza jest zdenormalizowana.

Silniki relacyjnych baz danych są związane z więzami integralności (constraint'ami) i bez względu czy masz OLAP czy OLTP to musisz się pogodzić z faktem, że są one tam uparcie
obecne bo silniki RDBMS powstały z myślą o ich wykorzystaniu.

Proszę o to samo w jednej linijce i bez marketingu.:>
"Można to zrobić, więc trzeba to zrobić" ?

Jeśli wsiadasz do samochodu i zapinasz do niego wołu to na ch** Ci ten samochód?

Może inaczej: klucze obce zapewniają spójność danych w jakimś wąskim zakresie. Żeby mieć pewność, że w bazie nie ma śmieci musiałbyś, oprócz kluczy obcych, wprowadzić do bazy masę checków, trigerów, itd. które zawierałby wiedzę domenową.

A to oznacza:
- rozsmarowanie domeny na kilku komponentach systemu.
- podwojenie pewnych prac związanych z implementacją (część domeny implementuje się 'na bazie', całą domenę implementuje się w aplikacji).

Jeśli baza ma zawierać całą wiedzę domenową (system obsługiwany jest przez bazę i tylko bazę) to nie ma sprawy - klucze obce, checki, procedury ją jak bardziej na miejscu.

Jeśli baza ma tylko 'przechowywać dane', to niech robi tylko to.

Temat: Diagram E/R w UML?

Ale to i tak sprawdza tester funk. biznesowej. Różnica będzie taka, że zamiast danych niezgodnych z protokołem dostanie 'error'.

Nie wyobrażam sobie, żeby taki test obejmował wszystkie przypadki...

Nie szkodzi. To wyobraża sobie analityk :)

Można ale w zależności od produktu te mechanizmy są inaczej realizowane.

To nie ma znaczenia. Ważne, że w tak samo łatwy sposób możesz osiągnąć ten sam skutek na dowolnym rdbms. I do tego są narzędzia, które model pomogą Ci utrzymać w oderwaniu od faktycznie wybranego silnika.

http://www.vistadb.net/onlinehelp/_2pi055atq.htm :>
Im więcej mechanizmów w systemie, tym większe prawdopodobieństwo problemów przy migracji.

Kończę rozmowę na ten temat.

I to świadczy tylko o tym, że nie powinno się 'omijać' systemu podczas importu danych.

Nie rozumiem. Nie omijanie systemu sprawi, że śmieci znikną w źródle?

W źródle nie - ale zapewni (walidacja), że śmiecie nie znajdą się w bazie danych.

Uznaję to za 'nie wiem'.

Hehe. Uznaj sobie za co chcesz ;-) Jak zrobię błąd w kodzie constraintu to najprawdopodobniej ujawni się on w momencie zakładania, albo przy pierwszych insertach. Więc jeszcze w czasie dewelopmentu.
Twój błąd pojawi się najprawdopodobniej dopiero na testach,

i tam powinien. testy to też "dewelopment".

albo (co gorsza) w czasie użytkowania...

po dobrych testach?

Skoro wielu twierdzi, że można sobie pozwolić na zdenormalizowany model danych (z czym się zgadzam),

Postać normalna dotyczy organizacji danych w tabeli i ma niewiele wspólnego z 'kluczami obcymi'.

Zgadza się. Constrainty stosuje się również z powodzeniem na modelach zdenormalizowanych, bo tam też pełnią pożyteczną rolę. Zawsze kontrolują spójność danych. A ty chcesz z nich z jakiegoś powodu rezygnować.

Bo logika spójności danych (jak i cała domena) powinna być w jednym miejscu w systemie.

Rozsmarowanie jej po całym systemie prędzej czy później zacznie sprawiać problemy.

Wyjaśnij mi. Po co w takim razie w ogóle stosować rdbms jak kontener na dane? Są jakieś zalety? Jeżeli tak, to jakie?

Są stabilne, jest do nich masa narzędzi, SQL zna większość programistów ... :)

Plik tekstowy. Jest stabilny. Jest masa edytorów. Pisany tekst zna większość ludzi...

Jaka zatem jest wyższość rdbms nad plikiem tekstowym?

plik tekstowy jest stabilny ...

Temat: Diagram E/R w UML?

Jakub Wojt:
http://www.vistadb.net/onlinehelp/_2pi055atq.htm :>
Im więcej mechanizmów w systemie, tym większe prawdopodobieństwo problemów przy migracji.

Kończę rozmowę na ten temat.

Jedna specyficzna sytuacja kiedy na jakimś silniku nie można założyć FK i wyrzucamy wszystkie constrainty do śmietnika. Nieźle.

I to świadczy tylko o tym, że nie powinno się 'omijać' systemu podczas importu danych.

Nie rozumiem. Nie omijanie systemu sprawi, że śmieci znikną w źródle?

W źródle nie - ale zapewni (walidacja), że śmiecie nie znajdą się w bazie danych.

Wątpię. Widziałem już takie systemy nie raz. I nie dość, że rozwiązanie nie było bardziej wydajne jak tu próbowaliście pokazać, to jeszcze wiele prostych spraw jak unikalność i referencje były programowane niepotrzebnie w myśl nie wiem czego... A na koniec dnia i tak wychodziły kwiatki.

I też już bym chciał na tym zakończyć ;-)

Hehe. Uznaj sobie za co chcesz ;-) Jak zrobię błąd w kodzie constraintu to najprawdopodobniej ujawni się on w momencie zakładania, albo przy pierwszych insertach. Więc jeszcze w czasie dewelopmentu.
Twój błąd pojawi się najprawdopodobniej dopiero na testach,

i tam powinien. testy to też "dewelopment".

Może ty użytkownikom dajesz do testowania rozgrzebany półprodukt. Ja przekazuję do testów gotowe rozwiązanie, aby sprawdzić, czy spełnia wszystkie wymagania.

albo (co gorsza) w czasie użytkowania...

po dobrych testach?

Tak.

Poza tym. Wiesz ile już widziałem "dobrych testów", które z politycznych względów muszą być zdane...

Bo logika spójności danych (jak i cała domena) powinna być w jednym miejscu w systemie.

Rozsmarowanie jej po całym systemie prędzej czy później zacznie sprawiać problemy.

Na prawdę życzę powodzenia. Praktyka pokazuje, że w z kontrolą spójności na aplikacji bywa marnie. I zostawmy już to.

Plik tekstowy. Jest stabilny. Jest masa edytorów. Pisany tekst zna większość ludzi...

Jaka zatem jest wyższość rdbms nad plikiem tekstowym?

plik tekstowy jest stabilny ...

A nie jest?

Temat: Diagram E/R w UML?

Bo logika spójności danych (jak i cała domena) powinna być w jednym miejscu w systemie.

Rozsmarowanie jej po całym systemie prędzej czy później zacznie sprawiać problemy.

Na prawdę życzę powodzenia. Praktyka pokazuje, że w z kontrolą spójności na aplikacji bywa marnie.

u kogo?

dobrze zaprojektowany system (oprogarmowanie) cechuje się, tym, ze zmiana domenowa (nowa stawka VAT, zmiana sposobu kontroli i naliczania wynagrodzenia i masa innych, sa implementowane we jednym miejscu. Jeżeli "logika biznesowa jest rozsmarowana po całym systemie) wprowadzanie podobnych zmian potrafi być kosztowniejsze od wytworzenia systemu.

Problem w tym, ze większość oprogramowania to kiepskie oprogramowanie (statystyki mówią o ok. 75%), tak wiec posługiwanie się argumentem w rodzaju "większość tak robi" lub "w większości rozwiązań zastosowano" nie koniecznie jest argumentem za wyższością danego rozwiązania czy technologii...