Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Ktorego wzorca najczęsciej uzywaja programiści do przejścia z klas w modelu dziedziny na fizyczna relacyjna baze danych? Pytam bo coraz częsciej mam niejasne wrażenie, że kurczowe trzymanie sie znormalizowanej bazy jest trudne w porównaniu z mapowaniem np. klas na tablice (gdzie obiekt to rekord), ktos z Wam uzywa np. mapowanai klasu na relacyjny model np. za pośrednictwem Hibernate?

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Używał :) NHibernate (w .NET). Męczące mapowanie, ale potem bardzo przyjemna praca. Oczywiście trzeba się nauczyć nowych rzeczy, za niektórymi sporo się przekopie w sieci. Jednak kolekcje obiektów (zamiast nawigowania po relacjach i ręczne złączenia), ściśle typowany kod (możliwość kontroli jeszcze w czasie pisania) rekompensują początkowo trudną naukę.

O wydajność Hibernate'a nie trzeba się zbytnio obawiać - przetestowane na korporacyjnym środowisku produkcyjnym (co nie znaczy, że nie da się tego spie...rniczyć :) ).

Chociaż np. u mnie nawyki relacyjne pozostały. Ponieważ swego czasu TSQL był dla mnie "całym światem", trudno mi się było przerzucić na ORMa. Często wolę "machnąć selekta" ręcznie na kliencie, niż instalować i konfigurować tego molocha. Właśnie dlatego na razie zarzuciłem NHibernate'a i pozostałem przy typowanych DataSetach w .NETcie. Nie są lepsze, są po prostu proste, a ja potrzebuję obecnie prostoty :)

PS: trochę dyskusji na ten temat można znaleźć na grupie .NET oraz pewnie na grupie Hibernate'a :)

Niestety, specjaliści są tu dość rozproszeni po rożnych grupach...Adrian Olszewski edytował(a) ten post dnia 01.09.09 o godzinie 17:55

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Adrian Olszewski:
Męczące mapowanie, ale potem bardzo przyjemna praca.

Nie zgodze sie z tym. Mapowanie obiektow w NHibernate jest proste jak barszcz :-), i opiera sie tylko na modyfikowaniu zawartosci pliku xmlowego (hbm.xml), ktory definiuje mapowanie obiektu na tabele w relacyjnej bazie danych.

O wydajność Hibernate'a nie trzeba się zbytnio obawiać - przetestowane na korporacyjnym środowisku produkcyjnym (co nie znaczy, że nie da się tego spie...rniczyć :) ).

Racja. Uzywalem NHibernate, na bazie z okolo 250 tabelami, gdzie w niektorych tabelach, rekordy ida w dziesiatki tysiecy.

Chociaż np. u mnie nawyki relacyjne pozostały. Ponieważ swego czasu TSQL był dla mnie "całym światem", trudno mi się było przerzucić na ORMa. Często wolę "machnąć selekta" ręcznie na kliencie, niż instalować i konfigurować tego molocha. Właśnie dlatego na razie zarzuciłem NHibernate'a i pozostałem przy typowanych DataSetach w .NETcie. Nie są lepsze, są po prostu proste, a ja potrzebuję obecnie prostoty :)

Obecnie korzystam wlasnie z typowanych DataSetow. Czasem ze strachu, przed przegenrowaniem DataSeta (bo rozne kwiatki wychodza), robie laty poprzez polaczeniowe ADO.NET.

Suma sumarum, nie podoba mi sie mechanizm DataSetow w C#.
A jedna z rzeczy, ktore mnie irytuja, dosc mocno, jest automatycnie generowany insert dla pewnego tableAdaptera.
Ktory bez recznej modyfikacji zwracanego typu z ExecuteNonQuery na Scalar, nie zwroci id wstawioego rekordu, tylko liczbe wstawionych rekordow.

Jest to o tyle upierdliwe, ze przy kazdym przegenerowaniu dataseta, znow sie zmienia na ExecuteNonQuery... i wychodza ladne kwiatki.

Pozatym podpinanie transkacji dla takiego adaptera, tez jest upierdliwe. Szczegolnie dla automaycznie wygeerowanych insert,select, update, delete.

Ogolnie bez wzorca Fasada nie umiem korzystac z tych mechanizmow, aby to mialo rece i nogi.

Nie wspominam o typowaych obietkach row, dla jakiejs tabeli, oraz kolumn ktore moga byc nullable. Trzeba miec, oczy dookola glowy, a NHibernate nas zwalnia z takich zachowan.

Suma sumarum, jakis belkot stworzylem... :-), ale jest na tak jesli chodzi o ORM, i mam nadzieje na projekt, w ktorym skorzystam z tego na powaznie.

Jarek Żeliński:

Ktorego wzorca najczęsciej uzywaja programiści do przejścia z
klas w modelu dziedziny na fizyczna relacyjna baze danych?

Tak sie wlasnie zastanawiam nad tym pytaniem. Czy poprzez "przejscie" rozumiemy, operacje bazodanowe i jak korzystamy z ORM?
Czy sam wzorzec, ktory by definiowal postepowanie podczas mapowania z obiektow na def. tabel w bd.
Tego powyzej nie znam, ale jesli chodzi o sama prace z NHibernate,
to korzystalem z dwoch prostych wzrocow Facade i Singletona (ktory dziedziczyl po pewnym interfejsie (Insert, Update itd). Plus co najwazniejsze chyba, mechanizm generic w C# (Insert<T>, Update<T>).Karol Błądek edytował(a) ten post dnia 07.09.09 o godzinie 09:03

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Swego czasu znalazłem artykuł który w bardzo treściwy i przystępny sposób opisuje różne strategie mapowania obiektów na model relacyjny. Polecam.

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

A co na temat Entity Framework? Ktos mial juz bezposrednie starcie i podzieli sie wrazeniami?

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Karol B.:
Jarek Żeliński:

Ktorego wzorca najczęsciej uzywaja programiści do przejścia z
klas w modelu dziedziny na fizyczna relacyjna baze danych?

Tak sie wlasnie zastanawiam nad tym pytaniem. Czy poprzez "przejscie" rozumiemy, operacje bazodanowe i jak korzystamy z ORM?
Czy sam wzorzec, ktory by definiowal postepowanie podczas mapowania z obiektow na def. tabel w bd.

No właśnie ja też mam problemy ze załapaniem sensu pytania. Czy chodzi o:
1. Wzorzec DataMapper i sposoby w jakie można go zaimplementować... ewentualnie o technologie go implementujące?
2. Porównanie Table Data/Row Gateway vs Data Mapper vs coś tam jeszcze?

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Alan, dokładnie o to pytałem. To często spotykane wzorce. Przejście z obiektowych modeli dziedziny na relacyjne modele repozytoriów było i jest wyzwaniem (np. projektowanie mapowań dla hibernate).

Pytanie zadałem w 2009 roku, w miedzy czasie powoli pojawiła się chyba odpowiedź: odchodzi się od baz relacyjnych i trzeciej postaci normalnej.... może nie jest to powszechne NoSQL (polecam w Google to hasło) ale sam zaczynam zaniedbywać relacyjności na rzecz agregatów i redundancji danych, wydaje mi się, że gwoździem do trumny RDBMS będą chmury: tu nie jest możliwa praca na centralnej znormalizowanej bazie danych ... każdy komponent jest samowystarczalny i dedykowany zarazem...

jak to u Was wygląda teraz?Jarek Żeliński edytował(a) ten post dnia 31.12.10 o godzinie 18:49

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

http://kosciak.blox.pl/2010/03/SQL-albo-NoSQL-oto-jest...

"U nas" (rozproszony system, sporo danych synchronizowanych w czasie rzeczywistym, bardzo złożone raporty, mnóstwo reguł) - czysto relacyjnie, z wykorzystaniem typowanych datasetów (termin z platformy .net) i data readerów (czyli czysty SQL).

W listopadzie przysłuchiwałem się dyskusji związanej z NoSQL (temat rzucony był jako ciekawostka na przerwie kawowej) i chociaż musiałem się "zmyć" dość wcześnie, to zdanie było podobne do tego n/t ORMów i można je streścić tak:

"w pewnej klasie problemów - możliwe, że pomocne i wydajne. W reszcie przypadków - możliwe, że się sprawdzi, ale tylko po gruntownym przemyśleniu za i przeciw. I być może to gruntowne przemyślenie nie będzie warte efektów, więc lepiej nie odchodzić od relacyjnych baz tam, gdzie to sprawdzone rozwiązanie."

Niestety, sam mam zbyt mało wiedzy, by produkować się na ten temat (nierelacyjnych DB), a obawiam się, że przeczytanie kilku artykułów mi nie wystarczy. Musiałbym popracować kilka ładnych lat bez przerwy z nową technologią, by znać jej za i przeciw na poziomie podobnym do tego z RDBMS (czyli w szerokiej klasie zastosowań i problemów) i móc stwierdzić, czy to tylko gadget, który nie przyjmie się na większą skalę, czy jesteśmy świadkiem narodzin czegoś, co kompletnie wyprze RDBMS, nawet w prostych aplikacjach i "ciężkim kliencie" (bo tego rodzaju aplikacje będą jeszcze pisane przez dekady).

Możliwe także, że zadziała tutaj mechanizm "generacji programistów". Obecnie "dzieci ORMów" mają często (oczywiście nie uogólniam) problemy z pisaniem złożonych i wydajnych zapytań SQLowych uzasadniając to tym, że takie potrzeby to w systemach wysoce złożonych, a 90% aplikacji biurowo-użytkowych tego nie wymaga. Z kolei "dzieci SQLa" nie trawią rozwiązań z ORMami (nawet tam, gdzie szkoda "brudzić ręce" SQLem). Kilka takich dyskusji: tutaj, tutaj i tutaj

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Adrian Olszewski:
Obecnie "dzieci ORMów" mają często (oczywiście nie uogólniam) problemy z pisaniem złożonych i wydajnych zapytań SQLowych uzasadniając to tym, że takie potrzeby to w systemach wysoce złożonych, a 90% aplikacji biurowo-użytkowych tego nie wymaga. Z kolei "dzieci SQLa" nie trawią rozwiązań z ORMami (nawet tam, gdzie szkoda "brudzić ręce" SQLem).

wskazane dyskusje to pytania "jak" a nie "czy" używać... moje doświadczenie projektanta:
1. baza relacyjna po zaprojektowaniu i napchaniu danymi jest w zasadzie niemodyfikowalna, ona sama zawiera w sobie znaczną część (czasami nawet całą) logiki biznesowej, niestety zamrożonej
2. proste tablice nierelacyjne, z możliwymi redundancjami, wymagają całej logiki w aplikacji, ale ich podatność na zmiany jest nieograniczona (a tego tyerz wymaga rynek)
3. obecne (nie tylko chmury), rozproszone architektury, gdzie integruje się coraz częściej podsystemy różnych dostawców, użycie centralnej bazy relacyjnej jest w zasadzie niemożliwe (znowu rynek).

Być może nie koniecznie NoSQL i hierarchiczne bazy (bo to także centralizacja), ale proste tablicowe (oparte na wzorcach typu active records lub bazach wprost lub quasi obiektowych) czyli repozytoria zarządzane przez specjalizowane aplikacje komunikujące się webserwisami doprowadzą do "wymarcia" baz relacyjnych normalizowanych, widać to już w hurtowniach danych....

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Jarek Żeliński:

Adrian Olszewski:
Obecnie "dzieci ORMów" mają często (oczywiście nie uogólniam) problemy z pisaniem złożonych i wydajnych zapytań SQLowych uzasadniając to tym, że takie potrzeby to w systemach wysoce złożonych, a 90% aplikacji biurowo-użytkowych tego nie wymaga. Z kolei "dzieci SQLa" nie trawią rozwiązań z ORMami (nawet tam, gdzie szkoda "brudzić ręce" SQLem).

wskazane dyskusje to pytania "jak" a nie "czy" używać... moje doświadczenie projektanta:
1. baza relacyjna po zaprojektowaniu i napchaniu danymi jest w zasadzie niemodyfikowalna, ona sama zawiera w sobie znaczną część (czasami nawet całą) logiki biznesowej, niestety zamrożonej

Owszem, ale mimo to, od 20 lat wielkie firmy IT sobie z tym (tzn. z problemem braku elastyczności przy nieustannie zmieniających się wymaganiach) radzą i to w sytuacji, gdy gwarantują (bo muszą) szybki serwis. Pewnie, że można to zrobić prościej i lepiej (i tutaj pole dla NRDBMS), co nie znaczy, że obecne rozwiązania uniemożliwiają pisanie systemów wrażliwych na zmiany. Potrzebny jest dobry analityk, który zaprojektuje elastyczną strukturę danych, a reszta - w kodzie. Jak w każdej dziedzinie :)

2. proste tablice nierelacyjne, z możliwymi redundancjami, wymagają całej logiki w aplikacji, ale ich podatność na zmiany jest nieograniczona (a tego tyerz wymaga rynek)

Zgoda. Ale i nie każda potrzeba rynku wymaga takich właśnie, nieograniczonych zmian w dziedzinie, rujnujących całą aplikację. I nie wszystkie systemy IT to systemy bankowe, społecznościowe (umieśćmy tutaj wszystko, co wyprodukowało Google), data miningowe - a to są właśnie systemy najbardziej IMHO podatne na zmiany, a jednocześnie o wielkich wymaganiach bezawaryjnej pracy (w niektórych przypadka nawet zdecydowanie kosztem wydajności). Mamy jeszcze kilkaset innych "gatunków" aplikacji.

3. obecne (nie tylko chmury), rozproszone architektury, gdzie integruje się coraz częściej podsystemy różnych dostawców, użycie centralnej bazy relacyjnej jest w zasadzie niemożliwe (znowu rynek).

Centralnej - nie, ale owe podsystemy, lokalnie... :) Czyli - kwestia zastosowania.

relacyjnych normalizowanych, widać to już w hurtowniach danych....

Ale hurtownie to nadal specyficzna działka i praktycznie zawsze dedykowana pod konkretne potrzeby. W końcu także hurtownie można uprościć do datamartów, które mogą mieć postać jednej gigantycznej tabeli... I tak to zwykle chyba jest, że mamy nierzadko bardzo złożone modele danych, które dla potrzeb raportowania i analiz zasilają DTO (np. takiego "dataseta"). I to często w osobnym procesie, który okresowo przygotowuje takie podręczne magazyny danych o prostej strukturze, z których następnie korzystają wyrafinowane mechanizmy analityczne.

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Adrian Olszewski:
Owszem, ale mimo to, od 20 lat wielkie firmy IT sobie z tym (tzn. z problemem braku elastyczności przy nieustannie zmieniających się wymaganiach) radzą i to w sytuacji, gdy gwarantują (bo muszą) szybki serwis.

moim zdaniem nie radzą sobie, na każde pytanie o "kastomizacje" od dostawcy ERP pada odpowiedz "nie" albo projekt ciągnie się miesiącami przy forsowanych uproszczeniach oczekiwanych funkcjonaności ...

Temat: z klas bo bazy czyli jaki wzorzec mapowania OR?

Cóż, na takie dictum nie mam odpowiedzi, bo musiałbym uogólnić, że nie radzą sobie, a tymczasem sam pracuję przy projekcie, w którym zmiany są częstsze, niż zgłaszane przez dział jakości bugi (no dobra, marzenia, ale i tak są częste :) ). Fakt, że to nie jest system klasy rozbudowanego ERP, więc i zmiany są zapewne prostsze do "wciśnięcia", ale ma w sobie sporo złożonych rozwiązań, jest rozproszony i o wysokiej dostępności (gdzie wprowadzenie zmian nie może położyć na łopatki klientów w całym kraju). OK, zapewne nie jestem do końca obiektywny, bo "każda pliszka swój ogonek chwali", ale dostawców oprogramowania jest mnóstwo, ba, są nimi także właściciele internetowych star-upów, gdzie "wywracanie flakami do wierzchu" nie jest "od Gwiazdki", tak, że nie czuję się w stanie użyć kwantyfikatora ogólnego :)

Co do wspomnianych dyskusji, o ile mnie jednak pamięć nie myli, gdzieś tam był spór o to, gdzie trzymać logikę, jak dostawać się do danych ("po co wam te ORMy? po co wam te SP? po co wam te mapowania"). Osobiście wskażę niejednego analityka z dużym doświadczeniem, któremu ERD do określania struktury danych oraz wybrane diagramy UMLa wystarczają (przy pełnej jego świadomości, że to nie jest podejście obiektowe, tylko hybryda). Czysto UMLowe podejście (a zatem obiektowe, a zatem bez anemicznych wzorców dziedziny i kombinowania) to nadal jednak rzadkość, chociaż młode pokolenia to zmieniają, bo już od początku uczą się "dobrych praktyk" i chcą podążać za trendami. Co jednak ciekawe, jakoś to wszystko działa :) (i tym trudniej ewangelizować w zakresie podejścia czysto obiektowego, bo "skoro działa, nie zawiodło, to po co mi tu Mercedes, jak Fabia wystarcza").

I kolejna sprawa - żyjemy w ciekawych czasach, gdzie mamy równolegle kilka specjalizujących się "światów". Sterowniki do urządzeń, silniki graficzne do gier i symulatorów, sterowniki przemysłowe (PLC), aplikacje małej i średniej złożoności do "prawie-każdej-działalności-usługowo-produkcyjnej" (od "akcesowej" bazy danych dla kiosku RUCHu, przez soft dla medycyny, po ERP dla małych i średnich firm), aplikacje edytorskie (DTP, prezentacyjne), ciężkie systemy zarządzania, rozproszone systemy giganty, a także systemy czysto internetowe - małe i większe start-upy, ale i giganty społecznościowe, jak uniwersum rozwiązań Google'a (od Google Health, przez Orcut, Gmail, Documents, YouTube (obecnie), Picasa i wiele innych), czy Microsoftu, w tym... "internetowe systemy operacyjne". Aha, no i systemy analityczne, powstające nieraz "na boku" głównego rozwiązania. To wszystko są różne światy, o różnych potrzebach w zakresie dostępu do danych, więc trudno powiedzieć, czy dla wszystkich NoSQL jest "przyszłością".

Ale że dyskusja zmierza na "standardowe szlaki filozoficzne", to czas chyba powrócić do wzorców...

------------
EDIT:
A propos Entity framework, mam podobne odczucia: http://www.goldenline.pl/forum/1506624/aspnet-jakiej-m...

Właśnie problemy z obsługą procedur wbudowanych dają się boleśnie we znaki przy ORMach, a SP są koniem pociągowym w wielu potężnych systemach o dużym współczynniku zmian logiki biznesowej, a specyficznych procedurach update'u.

Jest klasa systemów (bankowe, medyczne, telekomunikacyjne), gdzie łatwo o wymaganie, by struktura bazy danych umożliwiała pewnego rodzaju analizy, bez jakiegokolwiek dostępu do logiki biznesowej zaszytej w aplikacji i przy braku specjalistycznych rozwiązań w oparciu o hurtownie
danych. W tej sytuacji baza nieprzystosowana do takiego podejścia będzie raczej mało użyteczna. Wtedy stawia się na przetrzymywaniu dużej ilości reguł w bazie (od prostych "checków" po przez triggery, pakiety procedur i funkcji), ręczne tłumaczenie modelu obiektowego na model fizyczny, nawet za cenę czytelności i "czystości" modelu obiektowego i komplikowanie warstwy dostępu do danych.

Istotnym jest tutaj fakt, że elastyczność nie zawsze jest kluczem. Jest często pożądana (a czasem "do olania", z różnych względów), ale nie zawsze ma najwyższy priorytet.Adrian Olszewski edytował(a) ten post dnia 02.01.11 o godzinie 03:48