http://stronger.epsi.pl/2010/01/10/agile-database-modelling/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaThu, 29 Jul 2010 17:32:26 +0200JoggerPLhttp://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487144Czemu DBA mieliby mieć coś złego do powiedzenia w fazie prototypownia? Gorzej jakbyś takie herezje próbował wdrożyć na "produkcję", ale przecież napisałeś, że jesteś w stanie łatwo dodać kolumny. Dlatego zupełnie nie rozumiem po co w ogóle sugerujesz, że bazodanowcy są jakimiś gorszymi ludźmi.Sun, 10 Jan 2010 20:02:47 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487144http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487157Ahem. Tak więc, ja właśnie postuluję zastosowanie takich jak to nazwałeś "herezji" wszędzie, gdzie ma to sens - również na produkcji. Sam fakt nazwania dynamicznych kontenerów herezją wskazuje, że stoisz jak skamieniały na pozycji RDBMS-owego DBA. Ja natomiast twierdzę, że relacyjne bazy danych i SQL nie są w bardzo wielu przypadkach najwłaściwszym narzędziem. Są natomiast na tyle dobre, aby nadal ich używać w ogólności, a tam, gdzie nie dają rady (np. w przypadku dynamicznych schematów) łatać je na inne sposoby. Pewnie, że możnaby stworzyć osobną tabelę z kluczem obcym oraz kolumnami klucz i wartość, albo nawet osobne tabele na klucze i osobne na wartości, ale mogę na ślepo zaryzykować, że jeśli właśnie takie rozwiązanie jest odpowiedzią, to zadajemy złe pytanie. Właściwe pytanie to "jak szybko i wygodnie przechowywać dowolny hasz klucz-wartość?" a nie "jak przechowywać hasz klucz-wartość w relacyjnej bazie danych?". Dużo barwniej i w szerszym ujęciu tematu systemów otwartych pisał Steve Yegge w poście o wzorcu Property: http://is.gd/61rluSun, 10 Jan 2010 20:35:59 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487157http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487215Jezeli stosowac to rozwiazanie tam "gdzie ma to sens", to faktycznie masz racje ;) Ale troche odnioslem wrazenie, ze motywacja jest lenistwo - zamiast poswiecic troche czasu, zeby pomyslec jakie kolumny beda potrzebne, wszystko daje sie do JSONa. A przy odrobinie szczescie DBA tego nie zauwazy i wdrozy ;) A jesli chodzi o normalizacje wszystkiego, to nie od dzis (w sensie mody na nosql) wiadomo, ze trzymanie znienormalizowanych danych przynosi korzysci. Skoro w zapytaniu jest przykladowo jeden JOIN mniej, to moze byc to argument, zeby sobie odpuscic te purytystyczne podejscie.Sun, 10 Jan 2010 21:23:35 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487215http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487232@stronger: Proponowane przez Ciebie rozwiązanie jest na pewno kuszące z punktu widzenia programisty… ale już ja (DBA i System Integrator) bardzo ostrożnie bym do tego podchodził. Rozwiązanie jest fajne z punktu widzenia aplikacji w której zostało wdrożone. I twierdzenie, że „zawsze mogę dodać kolejną kolumnę” kiepsko się broni, gdy założymy, że Ciebie może już tam nie być, gdy będzie się trzeba do tych danych dobrać z czegoś innego. Aplikacje rzadko działają w próżni, a baza danych to często najlepszy „punkt styku” różnych elementów systemu. Ale cieszy mnie, że użyłeś JSON a nie jakiegoś egzotycznego formatu serializacji danych (walczyłem z aplikacją, która używała Java Serialization do utrwalania danych – właściwie trzeba było ją przepisać od nowa, bo takie rozwiązanie wręcz wykluczało nawet refactoring). I w ogóle miło, że jako programista uznajesz funkcję DBA – nawet w świecie „enerprisey” mam wrażenie, że większość programistów uważa że to tylko oni i ich program są odpowiedzialni za tworzenie i utrzymanie schematu bazy… >> Właściwe pytanie to "jak szybko i wygodnie przechowywać dowolny hasz klucz-wartość?" a nie "jak przechowywać hasz klucz-wartość w relacyjnej bazie danych?". Tu masz rację. Często niepotrzebnie się zakłada, że „jak chcę przechowywać dane, to używam relacyjnej bazy danych”. Z drugiej strony, jak ktoś wyjdzie z tego założenia i użyje bazy „zgodnie z regułami sztuki”, to się zwykle na tym nie przejedzie. Wymyślając własny sposób zapisu (w RDBMS lub nie) bardzo łatwo poważnie się pogrążyć. Jeszcze nie widziałem obiektowej bazy danych która sprawdzała by się dobrze poza bardzo szczególnymi wypadkami. Relacyjne bazy danych sprawdzają się bardzo dobrze w większości przypadków, gdzie trzeba przechowywać dane. Tyle, że schemat musi być dobrze przemyślany. W pewnych przypadkach zaproponowane przez Ciebie rozwiązanie na pewno się sprawdzi. Zresztą, to nic odkrywczego, często jest używane w praktyce (np. różne systemy GIS działają dość podobnie). Może się to jednak zemścić, gdy będzie stosowane rutynowo, tam gdzie lepiej sprawdziło by się „tradycyjne” relacyjne podejście.Sun, 10 Jan 2010 21:38:34 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487232http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487348@S: Lenistwo to niekiedy bardzo porządana cecha u programisty. Dobrze wytrenowany zmysł lenistwa to jak instynkt samozachowawczy. Zamiast żmudnego wplatania funkcjonalności w istniejącą hierarchię klas czasami łatwiej walnąć na to wszystko dekorator, a zamiast wikłania się w podejście SQL-owe od alfa do romeo (czy tam omega) lepiej zastosować jakiś bezschematowy magazyn. Przyspiesza prototypowanie i modyfikację systemu, ratuje od nudnego house keepingu. Nie jest również prawdą, że lepiej poświęcić trochę czasu by zaprojektować bazę poprawnie. I to z dwóch powodów. Przykład bezpośrednio z mojej pracy - duży system middleware z frontentem webowym i interfejsem SOAP dla telefonii VoIP działającej na infrastrukturze WiMAX. Na samym początku nikt nie był w stanie odpowiedzieć na elementarne pytania: jakie będą podstawowe składowe systemu, jakie są relacje liczności między nimi, jakie pola są obowiązkowe, a jakie unikalne. Zarys wymagań, schemat bazy oraz warstwę obiektową stworzyłem na podstawie odpowiedzi kierownictwa na pytanie jakie raporty chcieliby dostawać. Wyłaniająca się z tych odpowiedzi generalna zasada "zrób to tak, żeby można było robić wszystko, a później się zobaczy" nie pozostawiała mi nic innego jak zastosować stary, sprawdzony RDBMS tam gdzie się da, a resztę upchnąc w JSON-ie (mamy też formaty XML przechowywane poza bazą). Drugi powód, dla którego nie było lepiej zaprojektować staranniej bazy danych to fakt, że kierownictwo wyciąga nowe żądania niczym króliki z kapelusza. Dzięki kontenerom JSON wprowadzenie nowego pola nie kosztuje mnie nic. W przypadku SQL - musiałbym ręcznie rzeźbyć ALTERy, pamiętając przy tym o zrzuceniu/odtworzeniu widoków i triggerów. A taka zmiana w każdym szanującym się zespole pociąga za sobą konieczność uzyskania podpisów dwóch kierowników działów pokrewnych. Podtrzymuję z pełną świadomością co napisałem w poście - nie ma czegoś takiego jak "poprawny sposób". Jeśli ktoś uważa, że "poprawny sposób" czy "lepsza metoda" to SQL/RDBMS to tylko dlatego, że RDBMS to jedyne o co się troszczy. (Jeśli zaś chodzi o normalizację to jesteśmy chyba po tej samej stronie.)Mon, 11 Jan 2010 01:07:56 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487348http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487349@Jajcuś: Hoho, pan integrator! Gratuluję stanowiska. Zawsze mnie ciekawiło jak jest najwygodniej integrować systemy (tu znów przebija się lenistwo). To znaczy jakie jest idealne rozwiązanie dla SI? Zawsze myślałem, że gdy choć minimalna ilość logiki biznesowej leży poza bazą (np. w klasach) to idealnym rozwiązaniem byłoby kompletne API. Wówczas nie trzeba odtwarzać mechanizmów aplikacji macierzystej w integrowanym systemie. Pytam z dzikiej ciekawości czy rzeczywiście surowe dane to najlepszy punkt styku dwóch systemów. Rozumiem, że być może podejście "zawsze można dodać kolejną kolumnę" słabo się broni, ale raczej nie z tego powodu, że to już nie ja będę robił. Ponieważ LOB JSON-owy to rozwiązanie niestandardowe w świecie SQL-owych baz danych to mamy to dobrze udokumentowane i obwarowane restrykcjami. Argument, który może górować nad frywolnym poszerzaniem schematów, to nieznane zależności w innych widokach, wyzwalaczach i procedurach składowanych. I jest to rzeczywisty problem - dług wdzięczności względem naszej DBA rośnie jak inflacja w Zimbabwe ;-) > walczyłem z aplikacją, która używała Java Serialization Osobisty stosunek do developerów Javy trudno mi określić... Najbliżej wydaje się być słowo "niechęć", ale na odchodne korci mnie jeszcze przykleić do pleców karteczkę "moja stara tka szaliki z rdzeni ferrytowych" ;-) > jak ktoś (...) użyje bazy "zgodnie z regułami sztuki", to się zwykle na tym nie przejedzie. Za to bym głowy na pniaku nie położył. W moim przypadku decyzja o wyborze kontenera JSON do rozszerzania schematu bazy uratowała skórę. Gdyby nie otwartość siedziałbym tam poprawiając bez końca strukturę tabel bezsilnie patrząc jak lista TODO pęcznieje. Ponadto, baza klucz-wartość (np. CouchDB) znacznie lepiej sprawdzałaby się w znanych Ci BS-owych eDokumentach aniżeli zastosowany tam klasyk. Niestety, wówczas byliśmy zająci odkrywaniem Ajax-u, a hstore dla Postgresa jeszcze nie istniało. PS. Gratuluję ślicznego chłopczyka!Mon, 11 Jan 2010 01:08:45 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487349http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487388@stronger: Ja nie jestem taki „typowy SI”, po prostu uznałem, że SI to najlepsze określenie na to co robię. Tak podejrzewałem, że spytasz o API. Oczywiście, API jest najlepszym rozwiązaniem… ale SI zwykle wkracza do roboty wtedy, gdy takimi „normalnymi” interfejsami nie da się rzeczy połączyć. Twórcy któregoś z komponentów mogli zupełnie nie przewidywać, że będzie wykorzystany tak jak ma być wykorzystany, albo zupełnie nie przewidzieć łączenia go z innymi aplikacjami, więc API albo nie ma, albo zupełnie nie pasuje do problemu. Dostawca komponentu może być często już nieosiągalny, albo nie chcieć współpracować („takiego rozwiązania nie wspieramy”), a ostatecznie i tak chodzi o wyciągnięcie danych. I wtedy najprościej jest z RDBMS. Czasem wystarczy zrobić parę widoków i dwie zupełnie niespokrewnione aplikacje mogą działać z tą samą bazą. O ile, któraś z bazy nie korzysta zbytnio niestandardowo. Do Javy chyba mamy podobny stosunek (tyle, że mój do PHP jest nie lepszy ;)). Myślę że jej problemy wychodzą głównie z założenia, że jest to środowisko w którym „każdy głupi po paru kursach będzie mógł rozwijać enterprisey aplikacje”. I nie tyle drażni mnie sam język (chociaż stanowczo za dużo trzeba pisać, żeby nawet mało napisać), a to co w nim powstaje. Jako administrator wolę już wdrażać potworki w PHP niż te Javowe kombajny (biblioteki, czasem JRE, wraz z aplikacją, żadnego uwzględnienia czegoś takiego jak rozdział danych od kodu czy odpowiednie prawa dostępu do plików). „W moim przypadku decyzja o wyborze kontenera JSON do rozszerzania schematu bazy uratowała skórę.” Rozumiem. Ale to dlatego, że nie miałeś możliwości podejść do tego „właściwie”. Gdybyś od razu wiedział jakie dokładnie dane masz trzymać w bazie i jak mają one być potem przetwarzane i kiedy, i w jakich okolicznościach może się to zmienić, czy nie wybrałbyś jednak bardziej „standardowego” rozwiązania? Po prostu czasem trzeba stosować „hacki”, wręcz jest to najlepsze (więc i poprawne) rozwiązanie, ale dla konkretnego problemu. I trzeba rozumieć (i umieć to obronić) dlaczego w danym momencie się tego użyje. Hmmm… chyba Joel miał fajny artykuł niedawno na ten temat… O, jest: [The Duct Tape Programmer](http://www.joelonsoftware.com/items/2009/09/23.html)Mon, 11 Jan 2010 08:44:06 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487388http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487468Od czasu do czasu widuję systemy, które w relacyjnej bazie zapisują coś więcej, niż tylko proste typy. Jeszcze niedawno musiałem się męczyć z systemem, w którym ktoś postanowił przechowywać tak struktury XML-owe... I o ile początkowo to działało, o tyle po paru latach oryginalna motywacja tego rozwiązania zaginęła, a pozostał rozrastający się burdel. Ludzie zaczęli np. w XML-u odwoływać się do id wierszy w bazie... Były plany żeby to zrefaktoryzować, ale na tym etapie było to już praktycznie niemożliwe (w sensie: nikt nie chciał podjąć się analizowania tego, co programiści "(fr)agile" wyczyniali z formatem danych na przestrzeni lat). Innym problemem było utrzymywanie wersji obiektów (w bazie tkwiły zapisane i ich stare inkarnacje, i nowsze, odmienne rzeczy), warstwa kodu dostępowego trochę spuchła, bo zaczęła przejmować coraz więcej odpowiedzialności bazy danych. Z tego co wiem nadal to tak biega. Niezbyt wydajnie, i ludzie odpowiadający za business intelligence i data mining klną strasznie, ale działa. JSON byłby pewnie łatwiejszy do strawienia, choć i tak pewnie podatny na te same mutacje. To ten sam zarzut co wobec Javy -- jeśli uczynisz persistance bardzo łatwe w obsłudze (i nie zmuszające do ruszenia głową za każdym razem gdy reprezentacja danych się zmienia), to prędzej czy później przyjdą ludzie, którzy będą zmieniać rzeczy w sposób głupi lub nadmiarowy. Nie mam zamiaru bronić SQL-a, tylko zauważam, że rozwiązując jeden problem potencjalnie tworzy się inny. Koniec końców wszystko zależy od wymagań. Jeśli JSON w bazie je spełnia -- super, czemu by nie? Tylko nie wiem, czy "modelling" w tytule jest odpowiednim słowem -- tu chodzi chyba właśnie o uniknięcie modelowania bazy? BTW, stronger, tylko żałować Twoich doświadczeń z DBA. Chyba żaden z tych których ja napotkałem nie wielbił "złotej świątyni". Albo ja mam farta, albo Ty pecha, albo gdzieś to się wyśrodkowuje. Choć nie, autopoprawka -- niedawno spotkałem DBA, który miał fetysz stored procedures (że niby najlepiej jest, jak cały dostęp idzie przez stored procedures, a programiści nie wywołują ręcznie żadnych "niskopoziomowych" operacji). No ale to tylko jeden taki, i nikt go nie brał poważnie.Mon, 11 Jan 2010 14:43:17 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487468http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487630@Jajcuś: > [The Duct Tape Programmer] Mam tę książkę. Bardzo fajne postacie w niej występują. JWZ rzeczywiście wyróżnia się w szeregu, ale mój faworyt to Doug Crockford (JavaScript), natomiast w kategorii "urzekła mnie twoja historia" - Dan Ingalls (Smalltalk). > Gdybyś od razu wiedział jakie dokładnie dane masz trzymać ...to bym pewnie nie kombinował. Ale takie przypuszczenie jest tak dalece nierealistyczne w mojej firmie, że nawet nie przyszło mi do głowy wstawić stosowny disclaimer do powyższego wpisu. @Hoppke: Każdy system z biegiem czasu ulega erozji. Mam w pracy aplikację do planowania, która ma tabele liczące po 100 i więcej kolumn. Z używaniem dynamicznych schematów jest trochę jak z dynamicznymi językami - są niebezpieczne i łatwiej w nich o pomyłkę, ale jakimś cudem najlepsi programiści jakich znam używają właśnie dynamicznego typowania.Mon, 11 Jan 2010 22:54:11 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1487630http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1488031Miałem dłuższy komentarz, ale coś go wcięło po drodze (joggerowi się nie spodobał? :) Więc polecę skrótowo: "Każdy system z biegiem czasu ulega erozji." Jasne, ale nie wszystkie w tym samym tempie. A na tempo mają wpływ różne decyzje, w tym projektowe. "Z używaniem dynamicznych schematów jest trochę jak z dynamicznymi językami - są niebezpieczne i łatwiej w nich o pomyłkę, ale jakimś cudem najlepsi programiści jakich znam używają właśnie dynamicznego typowania." IMO dobry programista powinien dobierać narzędzia stosownie do problemu, nie kierując się obsługą typów (cecha wtórna...) Zarówno dynamicznie, jak i statycznie zarządzane schematy mają rację bytu. Zależy od priorytetów. Większość moich projektów zaczyna z dynamicznym schematem, by potem (gdy wstępny design już okrzepnie, a coraz ważniejsze stają się inne rzeczy) przejść na bardziej formalne zarządzanie schematem (lubię liquibase brać do tego celu, choć inni ludzie mogą woleć inne rozwiązania). U mnie powody są bardzo prozaiczne -- automatyczne generatory kiepsko radzą sobie z zakładaniem odpowiednich indeksów, tworzeniem widoków czy dobieraniem typów (chociaż np. Hibernate jest tu niezły), albo tabele muszą być współdzielone przez kilka aplikacji (aplikacja właściwa, aplikacja raportująca itp.), więc zmiany schematu muszą być kontrolowane. No i redukcja uprawnień -- aplikacja, która może tylko czytać/zmieniać wiersze jest już (w teorii) ciut bezpieczniejsza od takiej, która ma większe uprawnienia.Tue, 12 Jan 2010 22:28:46 +0100http://stronger.epsi.pl/2010/01/10/agile-database-modelling/#c1488031