Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

VB NET Klasy i MySQL jak to robicie

19 Wrz 2017 17:35 1599 33
  • #1 19 Wrz 2017 17:35
    1487300
    Użytkownik usunął konto  
  • #2 19 Wrz 2017 18:34
    lesławek
    Poziom 31  

    Mam złą wiadomość nie wymyśliłeś tego to już jest nazywa się LINQ...
    Poza tym używając twojego sposobu pozbawiasz się narzędzia jakim jest SQL, i w ogóle baza danych, masz klasę pracownicy ale chcesz wyświetlić raport krzyżowy w kolumnach miesiące w wierszach pracownicy, a na przecięciu np kwota zarobków i co? Dopiszesz metodę? No to nie wiem po co Ci ta klasa... Poza tym raczej wszystkie możliwe interakcje z danymi należy przerzucać na stronę serwera bazy danych, np tworzysz procedurę składowaną w niej zamykasz zapytanie. Wtedy w przypadku zmiany zapytania nie musisz modyfikować programu. Wystarczy tylko zmiana procedury na poziomie bazy danych.

    0
  • #3 19 Wrz 2017 19:35
    JacekCz
    Poziom 36  

    Kod: csharp
    Zaloguj się, aby zobaczyć kod
    Oprócz hasła LINQ to określane jest jako "per-zystencja", persistence, jest generalny (ogólniejszy) problem "object relational mapping", ma wiele zalet, ale niemało wad. LINQ jest można powiedzieć jedną z implementacji ORM.
    Twój przykład da się czysto wyrazić w ORM, niektóre są do wyrażenia dużym kosztem (drzewa, grafy, struktury nieregularne).
    Prawdopodobnie scenariusz który opisujesz (@hansklis ) jest obciążony problemem wydajnościowym, nie jestem pewien słowa ale chyba się nazywa N+1 fetch (wielość operacji z bazą dla jednego obiektu). Ale twój przykład nie traci elegancji, to jest "tylko" problem wydajnościowy.

    jakie są scenariusze sprzyjające ORM?
    Na pewna duża ilość kodu biznesowego. Jak dajesz 'Pracownik' to pociągnę : wyobraź sobie system kadrowo płacowy, 'oglądanie' danych pracownika od kilkudziesięciu różnych scenariuszy, pola do zapisu, pola tylko do odczytu, pola wyliczane wg skomplikownaych reguł (staż pracy zwykły, staż do urlopu, staże do dodatków branżowych - lata pracy do emerytury, niby 'tylko lata', ale każdy liczy się 'nieco' inaczej itd) i setki wydruków. Ma sens. W języku typowanym (.NET C# ale podobnie Java), w projektach utrzymywanych 10-20 lat to ma duże pozytywne znaczenie.

    Dla prostego, pojedynczego prezentowania w gridzie nie jest to optymalne, lepiej zrobić relację na SQL i prezentować kolumny kwerendy. W takiej opcji popieram kol. @lesławek (ale w szczegółach dodam: z tą procedura bazodanową to nie jest takie proste - zależy od punktu wyżej)

    EDIT: jeszcze jedno. Na pewno są sytuacje kiedy 'nie posiadający typu' wiersz z kwerendy trzeba potrzymać dłużej w RAM (tzn kwerenda ma bardzo wyraźnie bieżący wiersz i .... no właśnie, czasem trzeba mieć wiele wierszy jest na zasadzie kolekcji, listy) Jest na to sporo wzorców, z takich podręcznych to najważniejszy:
    Kod: csharp
    Zaloguj się, aby zobaczyć kod

    0
  • Pomocny post
    #4 19 Wrz 2017 19:56
    lesławek
    Poziom 31  

    JacekCz napisał:
    ola tylko do odczytu, pola wyliczane wg skomplikownaych reguł (staż pracy zwykły, staż do urlopu, staże do dodatków branżowych - lata pracy do emerytury, niby 'tylko lata', ale każdy liczy się 'nieco' inaczej itd)
    I te skomplikowane reguły miałyby być zaszyte w kodzie?

    0
  • #5 19 Wrz 2017 20:00
    1487300
    Użytkownik usunął konto  
  • Pomocny post
    #6 19 Wrz 2017 20:05
    JacekCz
    Poziom 36  

    lesławek napisał:
    JacekCz napisał:
    ola tylko do odczytu, pola wyliczane wg skomplikownaych reguł (staż pracy zwykły, staż do urlopu, staże do dodatków branżowych - lata pracy do emerytury, niby 'tylko lata', ale każdy liczy się 'nieco' inaczej itd)
    I te skomplikowane reguły miałyby być zaszyte w kodzie?


    Zapewniam Cię, jest im tam znacznie lepiej niż w procedurach SQL. Ujmijmy to tak, że 'trochę' o tym wiem.
    Co nie zmienia sytuacji, ze wiele procedur się używa, ale systemu złożoności w/w "Kadry-Płace" na tym nie zbudujesz.

    Edit. mam wręcz wrażenie, ze tradycyjne obszary 'relacyjne' jak PHP też przesuwają środek ciężkości na ORM. Cały biznes, gdzie właśnie obiekty fruwają w te i nazad (a nie mają już nic wspólnego z resulsetem SQL) , JS, AJAX, REST itd...

    Nie zrozum że to jest absolutne zwycięstwo 100:0, bo to nie w tych kategoriach

    0
  • #7 19 Wrz 2017 20:17
    lesławek
    Poziom 31  

    hansklis napisał:
    Co nie zmienia sytuacji, ze wiele procedur się używa, ale systemu złożoności w/w "Kadry-Płace" na tym nie zbudujesz.
    UNIT 4 TETA + oracle SQL + crystal reports Żadnej logiki biznesowej nie ma w kodzie... Zresztą nie wyobrażam sobie aby była... Co przy konieczności modyfikacji, rekompilacjia kodu?

    0
  • #8 19 Wrz 2017 20:22
    1487300
    Użytkownik usunął konto  
  • #9 19 Wrz 2017 20:45
    JacekCz
    Poziom 36  

    hansklis napisał:
    Ok to wracając do głównego wątku tematu kierunek mam dobry...? Jeszcze co jest pozytywne w moich wypocinach to łatwość pracy tych samych obiektów na bazie oraz plikach, przykład w przypadku braku połączenia z bazą program działa w trybie offline, dane zapisuje do xml z tymczasowymi id, przy połączeniu z bazą dane są wrzucone do bazy także można mocno zminimalizować awaryjność i konieczność bycia online, oczywiście w tych elementach systemu gdzie głównie odbywa się zbieranie danych. Np dodanie danych nowego klienta, to już kwestia rozwiązań.


    Dobrze myślisz.
    Oderwanie 'wiersza' od surowej bazy danych jest wiodące. A już drugą częścią jest pytanie, czy w postaci 'twardo typowanej' czyli klasy - czy map (w .NET mniejszościowo zwany Dictionary), zwróć na to uwagę. Pogooglaj 'active record' - podobna, choć to nie identyczna idea - jako lektura poszerzająca, a nie polecenie do realizacji.

    Powtórzę: nie odbierz tego jako "ewangelizację" 100% tylko na ORM, to jest gdzieś pomiędzy. W małych projektach nie ma sensu (zgodzę się z przedmówcą)

    lesławek napisał:
    hansklis napisał:
    Co nie zmienia sytuacji, ze wiele procedur się używa, ale systemu złożoności w/w "Kadry-Płace" na tym nie zbudujesz.
    UNIT 4 TETA + oracle SQL + crystal reports Żadnej logiki biznesowej nie ma w kodzie... Zresztą nie wyobrażam sobie aby była... Co przy konieczności modyfikacji, rekompilacjia kodu?


    Zapewniam Cię, że ma warstwy, a skoro tak, to wyższe nie jeżdżą po surowej bazie danych, tylko mają 'abstrakcje'.

    A ile tego kodu jest "twardego" (silnik aplikakcji, dla ilustracji C++), ile jest interpretowanego (zmienna wartość wdrożeniowa: formuły liczenia składki związku zawodowego dla 20 związków z zakładzie pracy), to inna opowieść trochę na marginesie wątku. Zwykle mają 'interpretery' reguł biznesowych, nie da się bez tego, i na pewno tym językiem nie są procedury SQL, bo nikt z pionów projektowych (w naszej ilustracji: specjaliści kadrowi) tego nie ogarnie. Są w wielowarstwowych systemach procedury SQL, ale z punktu widzenia logiki mają znaczenie tylko częściowe

    0
  • #10 19 Wrz 2017 21:35
    1487300
    Użytkownik usunął konto  
  • #11 20 Wrz 2017 10:38
    JacekCz
    Poziom 36  

    hansklis napisał:
    Cytat:
    Powtórzę: nie odbierz tego jako "ewangelizację" 100% tylko na ORM, to jest gdzieś pomiędzy. W małych projektach nie ma sensu (zgodzę się z przedmówcą)

    Jasne że nie 100%, pięknem pisania jest łączenie i płynne przechodzenie pomiędzy ideami wykonania projektu. Małych rzeczy mam już kilka za sobą ale chciałbym zacząć łowić wieloryby {duże aplikację} i nie chce na starcie iść w nietrafione technologie, jednak z Twoich wypowiedzi wnioskuje że na pewno nie marnuje czasu i taka metodologia na pewno jest warta poznania.
    Dodano po 37 [minuty]:
    I to jest pytanie obecnie używam właśnie twardego typowania, dzięki czemu mogę kontrolować dokładnie liczbę wykonanych poleceń do bazy mam już dobrze wypracowane metody oparte na system reflection i Property info przez co w klasie definiuje tylko właściwości (kolumny) reszta metod do łączenia z bazą insert select, update jest uniwersalne co fajnie skraca mi ilość kodu , mapowanie jakoś mnie nie przekonuje lecz jeśli jest wydajniejsze to chętnie się przesiade.


    1. Nie marnujesz.

    2. trochę mylisz zagadnienia. Twarde typowanie daje ci większe bezpieczeństwo gdy wystąpi literówka itd np pracownik. Nazisko będzie wychwycone jako błąd. (DataUrodzenia ma gwarantowany typ datowy a nie string, RozmiarKołnierzyka jest int, property Wiek da się tylko odczytać itd)
    W miękkim by tu się pisało pracownik.pole["nazisko"] z oczywistymi konsekwencjami.

    Wydajnośc to inne zagadnienie - nie mam pomysłu co krótkiego by doradzić. Akurat refleksja ma pewne koszty, ale sa to koszty mierzone w CPU i o wiele rzędów wielkości mniejsze niż operacje bazodanowe. Największy koszt to "N+1" czyli w uproszczeniu nadmierny koszt operacji dyskowej.
    masz link z kilkoma myślami. https://en.wikipedia.org/wiki/Object-relational_mapping - pogrzeb w kolejnych hasłach.

    EDIT: z czytania przypuszczam, że w ten inny sposób, ale tez robisz mapper

    W mojej opinii o ile środowisko (ekosystem, system+ludzie) .NET jest bardzo dobrze zrobionym remake Javy, i technicznie są bardzo podobne, to pewien sygnał edukacyjny, 'przekaz międzypokoleniowy' w .NET jest zbyt skażony praktycyzmem/ bardziej przesunięty do doraźnego praktycyzmu. Tzn programista .NET powie 'weź XxxxxxGrid' a programista Javy powie 'zastosujmy wzorzec Xyz'. Chce powiedzieć, że jak trafisz dobry artykuł na te tematy ze świata Javy, to nie zrobi Ci krzywdy, a jest ich wiele.

    EDIT2: puszczam koledze priv kilka wąsko specjalistycznych myśli - jak uznasz że mieści się w treści publicznego wątku, pomyślimy.
    EDIT3: odróżnia się 'lekkie' frameworki i ciężkie, ciężkie analizują zmiany w obiektach w celu opóźnionego ewentualnie zapisu (tego ani ty, ani ja nie zaimplementuję), w tym celu trzymają wszystkie 'dotknięte' obiekty w swojej sesji itd...

    lekkie dostarczają użytkownikowi obiekt 'i radź sobie', albo pozwalają na natychmiastowy zapis.

    Dał bym wzmiankę od dwóch, które mają podwójną implementację Java/.Net. W kategorii 'lekkich' MyBatis, w kategorii 'cięzkich' Hibernate/nHibernate (przy czym na gruncie Javy jest on jedną z wiodącym implementacji standardu JPA, w .NET jest samotnym tego rodzaju)

    0
  • #12 20 Wrz 2017 15:35
    1487300
    Użytkownik usunął konto  
  • #13 22 Wrz 2017 12:18
    JacekCz
    Poziom 36  

    hansklis napisał:
    Warto zwrócić uwagę na nhibernate, już miałem styczność z tym rozwiązaniem lecz jakoś odpuściłem temat. Nie wiem na ile moje myślenie jest słuszne ale Co mnie trochę wstrzymuje przed tym rozwiązaniem to tworzenie dodatkowych plików dla każdej tabeli/klasy i wydajność przy większej liczbie rekordów, na przykład tworzymy duża aplikację, powiedzmy 40 tabel, napisać trzeba 40 plików konfiguracji dla nhibernate, ponadto przeraża mnie utrzymanie stanu sesji, o ile w forms nie jest to problem to już ponowne użycie tej technologii w ASP NET może rodzic problem.

    Opisywanie klas w plikach XML nie jest już obowiązkowe, mogą być atrybuty na kodzie. O ile w javie (tam się nazywa adnotacje) zyskało to od dawna pełną akceptację, właśnie zerknąłem na dokumentację, w nHibernate nowa opcja mało entuzjastycznie zalecana. Nie wiem dlaczego.

    Moje myślenie jest 'pierwotnie javowskie' i przenoszone na C#, ale takie są te projekty.

    hansklis napisał:

    Po za tym teraz większe operacje zapisu wykonuje na osobnym wątku background worker, czy nhibernate pozwoli na wielowatkowosc nie tracąc issession?


    Po pierwsze w sensie ogólnym, wybór nHibernate się dokonuje ze względów na potencjał logiczny, a nie fizyczną wydajność.

    A z tym wątkiem zadałeś pytanie, przy którym medytowałem dłużej. Pewnie że można, więc dlaczego się nie robi? Chyba wiem. Trzeba mieć w warstwie wyższej (np GUI) jasne potwierdzenie, że zapis się udał, albo że poleciały wyjątki, transakcja się nie dokonała (do tego są przeznaczone te zabawki: wielopunktowe zapisy transakcyjne).

    To praktycznie zawsze ma "sens biznesowy", koszyk zakupu nie uzyskał potwierdzenia towarów, miejsce w samolocie nie zostało zarezerwowane, i rozstrzyganie tego nie należy do developera, tylko do zamawiającego 'biznesu' ("dla utulenia w smutku, proponujemy rabat na inny lot")
    We frameworkach tego typu 95% wyjątków leci dopiero w zakończeniu save() / commit(), nie można o tym nie wiedzieć (po drodze: pesymistic /optimistic locking i wiele innych zagadnień)

    Przykład przeciwny: śledzenie jak użytkownik chodzi po portalu, jakie artykuły odwiedza, jaka jest statystyka, prawdopodobnie nie ma żadnego znaczenia jak zgubimy 0,01% wpisów. Ale to założenie manager zamawiający u programisty też zatwierdził. (albo Like się ujawni kilka minut później, albo punkty reputacji Stack Overflow niby są, ale jakoś ich nie widać - czas)

    Jest ciekawy temat, teoretycznie nie jest związany z naszym punktem dyskusji (instalacja relacyjna na jednym hoście), ale fajnie naświetla przeciwieństwo miedzy wydajnością, konsystencją itd... muszą go znać wszyscy inżynierowie mikrousług, NoSQL, rozproszonych instalacji w chmurze itd...

    CAP theorem
    In theoretical computer science, the CAP theorem, also named Brewer's theorem after computer scientist Eric Brewer, states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency/ Availability / Partition tolerance

    https://en.wikipedia.org/wiki/CAP_theorem
    https://en.wikipedia.org/wiki/Eventual_consistency

    Sposób w jaki zadałeś pytanie, kojarzy mi się z tą teorią.

    0
  • #14 27 Wrz 2017 06:42
    1487300
    Użytkownik usunął konto  
  • #15 27 Wrz 2017 11:03
    JacekCz
    Poziom 36  

    hansklis napisał:
    Postanowiłem bliżej przyjrzeć się nhibernate. Ma wiele zalet i zaczął mnie przekonywać ale natrafiłem na pierwszy problem i nie znalazłem jeszcze rozwiązania. Co kiedy mam bazę z replika, na głównej db wykonuje insert i update a z repliki select, nie bardzo wiem jak to rozwiązać z użyciem nhibernate, czy trzeba tworzyć dwie instancjie obiektu, dla read i write żeby w pełni wykorzystać możliwości nhibernate?


    Pytanie w zasadzie poza moim zasięgiem (poniżej dlaczego)
    1. frameworki "z sesją" bardzo mocno bronią 'braterstwa' jedna encja w bazie - TYLKO jeden obiekt w RAM. To jest fundamentalne (są doktoraty nt klucza pierwotnego / hash obiektu, porównania tożsamości itd)
    2. moje rozumienie tego co piszesz, jest bliskie wzorcowi CQRS (wiele materiałów, w tym po polsku), czyli zupełnie inny przebieg zapisu, zupełnie inny odczytu. CQRS porzuca frameworki "sesyjne" czy "ciężkie", optymalne sa proste warstwy obiektowe nad driverem bazy, inne w nurcie zapisu, inne w odczycie.
    https://martinfowler.com/bliki/CQRS.html
    https://www.youtube.com/watch?v=HQSeEJ6BnDM
    https://www.youtube.com/watch?v=Emr4jkhW9L4
    https://www.youtube.com/watch?v=yud0XiU65ko

    Moja wypowiedź bazuje na świecie Javy. Nigdy tam się nie robi z jednego EntityManagera zapisu do rozproszonych baz. Jesli juz jakoś się rozprasza, to mnoży się całe serwery aplikacyjne (tego zdania nie łącz z CQRS - to coś innego)

    Notka historyczna. Tzw J2EE zawierało m.in. EJB-2 (dziś uważane za mocno przestarzałe), a to opierało się na 'Remote interface', i złożonością rzucało na kolana. Potem było nowatorska JEE 5 ... kilka dni temu oficjalnie wydano JEE 8. Specjaliści podkreślają że w standardzie ogóle zniknął temat clastrów (mogą być 'propertiary' implementacje oczywiście). Presja na 'remote interface' całego wielkiego serwera znacznie się zmniejszyła, być może nawet stając się niepotrzebną, przez rewolucję mikrousługową.


    Zapraszam do świata Javy. Tam się myśli tak, jak lubisz. Jest ogrom dokumentacji.
    Dla wyjadacza C# Java SE (czyli 'standardowa) to jeden wieczór (stringi się porównuje przez equals() ). Enterprise nie jest na jeden wieczór, ale to bardzo ciekawy świat. nawiasem mówiąc proces rozwijania nowych wersji JEE właśnie dostał kolejnego etapu 'demokratyzacji' , będzie totalnie opensurs. Wszystkie dyskusje specjalistów, projektowane drafty standardów sa normalnie dostępne dla zwykłych ludzi (od dawna).

    0
  • #16 03 Paź 2017 18:52
    1487300
    Użytkownik usunął konto  
  • #17 04 Paź 2017 11:32
    JacekCz
    Poziom 36  

    hansklis napisał:
    Z Javy kojarzę biblioteki spring jdbc, z zresztą bardzo fajne do współpracy z bazą danych, ot taki mapper ale bardzo wg mnie przyjemny, właśnie nhibernate przypomina mi spring. Przestudiowalem twoje linki, dzięki bardzo bo znacznie poszerzylo to moje spojrzenie na pewne rzeczy. Właśnie czytam wieczorami dokumentację, sample dla Javy może i czas na zmianę całej platformy.


    Ja przychylam się do tej części branży, która wieszczy schyłek, albo już osiągnięcie maksimum przez Spring. Daaaawno temo to on był "lighweight".

    Używanie spring-jdbc (a używam - mam wieloletni projekt gdzie tylko to) ściąga pięc innych jego modułów i 10MB. "W onym czasie" było to jedyne środowisko gdzie były nazwane parametry SQL (wszystko inne były pozycyjne) - dziś już to nie jest tak. W nowym kodzie nie używam. Wstrzykuję Guice'm (o ile nie w kontenerze JEE)
    Spring ze wstrzykiwaniem zależności pojawił się, jak Java Enterpsies była ułomna. De facto zbudowali stos "enterpajzowy" obok standardowego stosu

    Dziś są liczne blogi jak częściowo / całkowicie zmigrowac się ze Springa na nowoczesną zestandaryzowaną JEE (Adam Bien, Antonio Goncalves i inni niezależni eksperci). Mnie osobiście to przekonuje, choć mam świadomość produkt z tak mocną obecnością nie zniknie. Zwłaszcza w realiach korporacyjnych siedzących na J2EE, Java 1.4 i Spring

    0
  • #18 06 Paź 2017 15:32
    JacekCz
    Poziom 36  

    lesławek napisał:
    No to nie wiem po co Ci ta klasa... Poza tym raczej wszystkie możliwe interakcje z danymi należy przerzucać na stronę serwera bazy danych, np tworzysz procedurę składowaną w niej zamykasz zapytanie. Wtedy w przypadku zmiany zapytania nie musisz modyfikować programu. Wystarczy tylko zmiana procedury na poziomie bazy danych.


    Zainspirowałeś mnie kilka tygodni temu w/w słowami, zacząłem patzrec przez te oklurary. Niestety Cię zmartwię, zrobienie w SQL czegoś, co bardzo naturalnie by było w warstwie pośredniej (sztuczne wiersze po zmianie warunku itd), ale również sztuczne (wirtualne) kolumny (zwłaszcza te, których wartość ma pochodzenie 'pionowe'), przy wielkim talencie SQL da się zrobić, ale to jest kod 'write only' (słówko z kontekstu wyrażeń regularnych w Perlu), refaktoryzacja, zmiana funkcjonalności, poprawki nie wychwyconych błędów jest niemal niemozliwe, to daje się tylko wyrzucić i zrobić jeszcze raz.

    JacekCz napisał:
    Dziś są liczne blogi jak częściowo / całkowicie zmigrowac się ze Springa na nowoczesną zestandaryzowaną JEE (Adam Bien, Antonio Goncalves i inni niezależni eksperci).


    Ciekawostką ujęcia Adama Bien'a jest w prostych projektach postuluje zmniejszenie ilości warstw *) . Facet uznaje, że otoczenie biznesowe jest takie, że dla wielu z tych projektów nigdy nie powstanie "daleko idąca przyszłą zmiana", która by uzasadniała (przykładowo) święte korporacyjne cztery-pięć warstw.
    Nie chciałbym być źle zrozumiany, nigdzie nie proponuje programu jednowarstwowego.

    *) np teza, kontrowersyjna dla niekórych ale niegłupia dla mnie, że współczesne JEE jest na tyle eleganckie i elastyczne, że eliminuje (w niektórych projektach) potrzebę DAO

    0
  • #19 06 Paź 2017 16:44
    1487300
    Użytkownik usunął konto  
  • #20 06 Paź 2017 19:04
    lesławek
    Poziom 31  

    Hmm... systemy które znam tzn SAP ALV, SmartForms, SAPScript, Czy Teta constellation, dają użytkownikowi dostęp do bazy, czyli musisz napisać zapytanie samodzielnie, chyba że one są mało zaawansowane, a gdzieś jest jakiś system o którym nie wiem, natomiast generatory raportów rzeźbione na piechotę mają zwykle bardzo ograniczone możliwości...

    0
  • #21 06 Paź 2017 19:34
    JacekCz
    Poziom 36  

    hansklis napisał:
    Ok a czy dalej warto korzysta z tzw summary table aby szybciej generowac np raporty, np wszystkie zamówienia w tabeli z dnia sumuje i wrzucam jako jeden wiersz do drugiej tabeli z której jest odczyt danych do raportu?

    1. Sumowanie "aktywne" do innego miejsca w bazie relacyjnej .... jest to obecne w branży. Czy coraz więcej, czy mniej?
    Na pewno to nie zginie, ale wiem o systemie ERP który nie trzyma stanu magazynowego na dzień X, tylko go podlicza (dawne systemy miały obowiazkowo stan na zamykane okresy)

    Na poziomie teorii baz relacyjnych - sumy robocze obalają "trzecią postać normalną" bazy danych

    2. Systemy raportowe (czyli użyje słowa "podsumowanie bierne") niemal nigdy nie używają sumowania z SQL. Jak w matematyce bardzo łatwo jest obalić kwantyfikator ogólny, tak tutaj kolumna wirtualna i tak zmusi silnik raportów do przejrzenia wszystkich wierszy, i tak.

    Na marginesie, całkiem niedawno jeden blog dał mi do zrozumienia, że w "big data" nie ma czasu rzeczywistego ze względów najbardziej podstawowych, sam przebieg zjawisk.
    Co do raportów: nie warto się chlastać, zanim w Twoim przykładzie sekretarka da prezesowi podsumowanie dnia, minie od minuty do godziny (nawet jak prezes samo sobie to klika - wypije kilka łyków kawy następnego dnia przed południem). Od banków (stan na wczoraj), FB, StackOverflow wszędzie są opóźnienia, które niczego negatywnego nie pociągają. Być może punkty Elektrody sa ostatnim rankingiem w miarę w czasie rzeczywistym???


    hansklis napisał:

    Jacekcz widzę że masz bogate doświadczenie, miałeś może styczność z hadoop?


    Zmartwię Cię, nie da się mieć doświadczeń ze wszystkim. Całą branże NoSQL jak na razie znam trochę z czytania i demo. Lubię łykać wiedzę, ale nie da się wszystkiego w produkcji dotknąć.
    EDIT generalne spojrzenie na bazy NoSQL i nowy styl użycia jaki przynoszą, mam na myśli głownie 'eventual consistency', zagadnienie godne Heissenberga (pewny jest albo czas, albo dane), ma głęboki wymiar psychologiczny czy 'religijny' dla kogoś, kto prowadził bazy z pieniędzmi, i wszelka spójność była święta. Zależnie od stopnia "zabetonowania się" na bazach ACID relacyjnych, spora przemiana w głowie.


    hansklis napisał:

    Co do przenoszenia wszystkiego na serwer, wyobraźmy sobie system który umożliwia tworzenie szablonów raportów do wypełnienia w formie tabeli. Definiujemy liczbę kolumn typ danych w kolumnie itd. Użytkownik może przygotować dowolny szablon tabeli np zamówienia określić nazwy kolumn itd, dane zapiszemy w tabeli składającej się z kilku kolumn gdzie każdy wiersz ma numer kolumny i numer wiersza, np tabela 3 kolumny 3 wiersze zostanie zapisana w 9 wierszach, w osobnej tabeli będzie konfiguracja nazwy kolumn, zestawienia, wg mnie złożenie z takiej postaci tabeli poprzez sql jest karkolomne.






    Oprócz Twojego argumentu o trudności implementacji, j/w najprostsza kolumna wirtualna obala taki tok myślenia. Zgadzam się.
    Po drugie konserwacja kwerend SQL jest naprawdę niewdzięczna, to awykonalna dla amatora. Nawet w korporacyjnym IT uważa się to zajęcie dla kogoś innego niż programista kodu aplikacji.
    Oprócz względów historycznych (syntax jest jaki jest), SQL jest językiem deklaratywnym (wyj: procedury SQL) , gdzie w algorytmicznym wyrazimy się o wiele wygodnie (i większym zakresie)

    hansklis napisał:

    Co do przenoszenia wszystkiego na serwer

    Dlatego mówimy nie tylko serwerze SQL (bazy danych), ale o serwerach APLIKACYJNYCH
    Dodano po 9 [minuty]:
    lesławek napisał:
    Hmm... systemy które znam tzn SAP ALV .... SAPScript ... dają użytkownikowi dostęp do bazy, czyli musisz napisać zapytanie samodzielnie


    Nie w ABAP-ie? Byłbym zdziwiony. Jesteś pewien że to nie druga czy kolejna warstwa 'podobna' do bazy danych?
    A SAP R/3 o fizycznej bazie można było tylko podumać

    Już pominę, że designer d/s bezpieczeństwa bazy danych SAP by za taki pomył by rozstrzelał (przecież sa tam miliony danych poufnych innych dla każdego 'credentiala'), a reguły są nie tylko 'pionowe' (jakby co do kolumn - tu być jeszcze dawał argument z 'GRANT') ale ogrom reguł jest 'poziomych' (do wybranych wierszy). Nie wyobrażam sobie bez warstw.

    EDIT: jak widzę większość ludzi na Elektrodzie ma problem z makrami excella, czyli oprogramowaniem zero-warstwowym. W ujęciu von Neumanna to w ogóle nie jest oprogramowanie). My to chyba jak czerwony krasnoludek w zielonym lesie na zielonej polanie za zielonym jeziorem :)

    0
  • #22 06 Paź 2017 20:17
    lesławek
    Poziom 31  

    JacekCz napisał:
    Nie w ABAP-ie? Byłbym zdziwiony. Jesteś pewien że to nie druga czy kolejna warstwa 'podobna' do bazy danych?
    A SAP R/3 o fizycznej bazie można było tylko podumać

    Trochę masz rację, właściwie jest tam Open SQL czyli taki jakby uproszczony SQL, który jest faktycznie warstwą abstrakcji bazy danych, w kontraście do tego masz też Native SQL który jest już bezpośrednio na bazie. niemniej jednak z punktu widzenia programisty program ABAP wygląda jak "przekładanka" Open SQL/Native SQL i samego ABAPu.

    0
  • #23 08 Paź 2017 14:34
    1487300
    Użytkownik usunął konto  
  • #24 09 Paź 2017 12:31
    JacekCz
    Poziom 36  

    hansklis napisał:
    Też macie wrażenie że wraz z postępem i mnogościa technologii zaciera się granicą pomiędzy warstwami aplikacji tzn podział na db core i ui jest bardziej rozdrobniony ...


    Zbieżna z Twoją jest moja myśl, że jedna ze "świętości" tzn wzorzec MVC (Model-View-Controller) staje się tylko jedną z alternatyw czy zanika.
    Na gruncie web+Java używam głownie Apache Wicket, z modeli teoretycznych najbliżej mu do MVVC. Uczyłem się i prowadziłem dyskusję z człowiekiem pracującym dla Vaadin, również "najbliższy" wzorzec teoretyczny to MVVC, a ilość warstw w przypadku użycia JPA (~= nhibernate) to ustalenie "warstw jest trzy i pół"

    Wrócę do skrótu CQRS, też inna ilość "warstw" albo warstw w odczytach/zapisach. Cudzysłów dlatego, że w ogóle słowo "warstwa" jest poddawane próbom podważenia. Z argumentacją, że istnieje w OOP jako przeniesienie z poprzednich "paradygmatów".

    Ale z drugiej strony współczesne przemiany (mam przed oczami UI robione client-side we frameworkach javasriptowych przez specjalizującego się tylko w tym 'frontendowca'), podział tej warstwy jest bardziej wyrazisty (wręcz radykalny). Frontedowiec jest dziś królem, mam być animowane, kolorowe, mieć skórki, 'intuicyjne' itd ....
    W każdym profesjonalnym systemie powinna odpowiadać mu warstwa server-side, CHOĆBY dla server-side walidacji czy selektywnego utajniania danych (jedną z większych głupot chaotycznego UI po stronie klienta jest walidacja client-side jako jedyna, dość przerażające jak to przemyśleć). O nieprofesjonalnych (a na pewno są) będziemy się sukcesywnie dowiadywać z "komputerowych" działów na głównych portalach.

    0
  • #25 09 Paź 2017 18:15
    1487300
    Użytkownik usunął konto  
  • #26 09 Paź 2017 19:26
    JacekCz
    Poziom 36  

    hansklis napisał:
    Mam takie też prozaiczne rozterki, mianowicie:
    Jak zaopatrujecie się na przechowywanie w bazie danych typu blob... w bazie tylko ścieżkę do pliku, lub trzymać się tylko bazy danych. Spotkałem każde z tych rozwiązań lecz nie wiem czy jest jakaś zasada.


    Obie / wszystkie trzy:)
    Podobno w IT tzreba wykuć na pamięć słowa "to zależy"

    W bazie, w plikach ze ścieżką. A zwracany może być plik, ścieżka zwracana do klienta może być b) stała i dostępna poza aplikacją, lub c) zmienna (ulegająca unieważnieniu - zw z serwowaniem przez aplikację w obrębie jakiejś sesji *) ).
    W schyłkowych latach 90 budowało się (próbowało???) intranety zwracające adres plikowy po SMB, zwykle na file systemie ReadOnly. Samo pobranie pliku następowało poza w/w aplikacją.
    Dziś by to pewnie było HTTP (po to kiedyś powstał WEB-DAV ale o nim nie słychać obecnie).

    Są dwie architektury: M-architektura i T-architektura (nie moje, wyczytane. Pierwsze od marketing, drugie od technika. Decyzje architektoniczne powstają pod wpływem obu, np moduły w zintegrowanej aplikacji, bo lepiej sprzedawać oddzielnie moduły).
    Zależy od spodziewanej statystyki tych plików, np na dolnym rynku królują bazy Express, albo cienkie serwerki z pojedynczymi GB pamięci. Czy (twoje XML **) ) masz założenie przeszukiwać, czy tylko 'czarna skrzynka' ...
    Znam dobrą aplikację, gdzie filozofia załącznika jest do wyboru w opcjach wdrożenia.

    *) jak pobierasz z różnych źródeł darmowe programy, widać obie filozofie, URL jest stały, albo sesyjny po podaniu maila.

    **) bazy całe w sobie (MongoDb) albo jako opcje (MySQL, Postgres) coraz częściej mają filozofię 'dokumentową', pewnie częściej znajdzie tam dokumenty JSON, ale coś do XML bywało, i to od dawna

    0
  • #27 09 Paź 2017 20:21
    1487300
    Użytkownik usunął konto  
  • #28 09 Paź 2017 20:40
    JacekCz
    Poziom 36  

    hansklis napisał:
    Ok a czy jest różnica wydajnosciowa pomiędzy zapisem pliku w bazie a fizycznie na dysku twardym serwera? Rozpatrujemy przypadek gdy zawartość pliku jest czarna skrzynka, po utworzeniu możliwy tylko odczyt.


    Klasycy mówili, żeby nie trzymać, bo to kosztuje, baza tak obciążona staje się mnie wydajną innych aspektach.

    Dzis można mówić że trzymać, się. Argumenty "za" też znajdzie: dysk sformatowany na sektory 16KB, przyjmie tam jeden plik, nawet nie wyczerpujący powietrzni, i więcej zmarnuje. Baza jest właścicielem ciągłej przestrzeni, dwa male pliki umieści obok, i mało sektorów zajmie. NA pewno jest narzut CPU na wykonanie zapisu/odczytu tego klocka, ale tracona powierzchnia nie musi być większa, niż by leżał na file-systemie

    Żaden przejmujący sie robotą admin nie lubi, jak baza puchnie, a od załączników puchnie odczuwalnie. Jak? Zależy w każdym wdrożeniu

    Jak długo to jest w bazie w jakiejś większej farmy serwerów, jest centralnie backupowana, może ciągłą shadow kopia na drugą, w jednej czynniści administracyjnej załatwiamy dane proste i załączniki

    Dużo zależy od liczb, czy jesteśmy zespołem 10 ludzi, biblioteką miejską. czy kongresem US.
    W dostatecznie dużej firmie (i zespole IT) znajdzie się inna dobra baza do załączników, inna dom treści bazy

    https://www.youtube.com/watch?v=VXeZNira1Jg
    W filmie ok 20-30 minuty omawia jak w ramach jednej logiki eksploatować dwie zupełnie inne bazy

    0
  • #29 10 Paź 2017 19:46
    1487300
    Użytkownik usunął konto  
  • #30 10 Paź 2017 20:40
    JacekCz
    Poziom 36  

    @hansklis To Twój wątek, ale przyjemnie by było tu dyskutować o zawiłościach modelu relacyjno-obiektowego, a implementację BLOB wydzielić do innego

    0