Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Likus:
Nie jest zły, też używałem, ale zdaje się że daleko mu do PostgreSQL - który też jest darmowy. Duża zaleta to możliwość wykorzystania w wersji embedded - jako DLL do programu bez dodatkowych serwisów i cichych instalatorów.
Ale i na tym polu jest konkurent - SQLite.

No i MSSQL Compact Edition.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

1) Oracle + SQL+ PL/SQL + Pro*C
2) PostgreSql + SQL + PL/PGSQL

I najważniejsze to natłuc sobie do czaszki, że baza po to ma możliwość trzymania pakietów i procedur/funkcji żeby z tego korzystać jak najwięcej i jak najczęściej i logikę biznesową liczyć właśnie z pomocą bazy a nie warstwy do tego nie odpowiedniej. Bo po to tyle się płaci za licencję i po to kupuje się szybkie maszyny pod serwery DB żeby miały co robić a nie całe życie select, update, insert bo instalacja Oracla po to żeby trzymać w nim dane tylko to jak spuścić bombę atomową żeby zabić jednego komara.

Pozdrawiam Michał.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Michał Bożek:
1) Oracle + SQL+ PL/SQL + Pro*C
2) PostgreSql + SQL + PL/PGSQL

I najważniejsze to natłuc sobie do czaszki, że baza po to ma możliwość trzymania pakietów i procedur/funkcji żeby z tego korzystać jak najwięcej i jak najczęściej i logikę biznesową liczyć właśnie z pomocą bazy a nie warstwy do tego nie odpowiedniej. Bo po to tyle się płaci za licencję i po to kupuje się szybkie maszyny pod serwery DB żeby miały co robić a nie całe życie select, update, insert bo instalacja Oracla po to żeby trzymać w nim dane tylko to jak spuścić bombę atomową żeby zabić jednego komara.

Pozdrawiam Michał.

szczytne idee, lecz to herezja dla programistów oni tylko ORM-y uważają za jedyne i słuszne rozwiązanie :)

pewnie po części że nie chuchu nie umieją programować w SQL-a (dowolnym), ba mają problem z SELECEM jak jest bardziej udziwniony

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Tu nie o tłuczenie czaszek chodzi przecież :) Ani o ORM-y.

Dopóki nie powstanie jednolity system, umożliwiający wspólne wersjonowanje wszystkich warstw systemu, do tego czasu 99% kodu będzie znajdowało się w tej warstwie, która wersjonuje się najłatwiej.

Jak sobie wyobrażacie, Panowie, sytuację, kiedy to usuwamy kolumnę z jakiejś tabeli, a potem (za pół roku) chcemy wrócić do wersji sprzed usunięcia?
Przecież tabele zawierają dane? I co, przy usuwaniu kolumny mają być zapamiętywane usunięte wartości wraz z ich powiązaniami? Przecież w chwili odtwarzania tabela może zawierać już całkiem inne wiersze? A jeśli na tym stoją jeszcze jakieś triggery?
Nie wyobrażam sobie tego - nie wyobrażam sobie nawet, jak to można by było zrobić. Ale pewnie cienki bolek jestem.

Nie wspominam tutaj o legendarnej wręcz łatwości debugowania kodu procedur składowanych, bo chyba wszyscy wiedzą jakie to proste :)

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Wystarczy, że wersjonujesz DDLe i DMLe.
Przecież nie ma problemu żeby wersjonować trigger czy pakiet czy opis tabeli.
Co do danych to zwykle się dokłada nie zabiera(najwyżej nie używa)
Pozatym istnieje takie pojęcie jak branch i merge.
Pracuje od dłuższego czasu stosując takie rozwiązania przy na prawdę ogromnych systemach i nie miałem jak do tej pory większego problemu z wersjonowaniem.

P.S Co do debugowania to fakt jest legendarne i niestety wyprzedza często legendy o sobie :)

Jednak wady te są niczym wobec jednej głównej zalety jaką jest wydajność a uwierz mi, że kiedy męczysz joina na tabelach, które mają po kilkadziesiąt kolumn i kilkanaście milionów rekordów a czasem niestety trzeba i do tego coś na tych rekordach musisz zrobić dalej to różnica między taką operacją w bazie za pomocą PL/SQLa a HIBERNATE sięga dni :)Michał Bożek edytował(a) ten post dnia 20.10.10 o godzinie 14:51

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Michał Bożek:
Wystarczy, że wersjonujesz DDLe i DMLe.
Przecież nie ma problemu żeby wersjonować trigger czy pakiet czy opis tabeli.

Ok, a czy są dobre narzędzia, którymi jednocześnie mogę wersjonować i kod aplikacji (np. w C#), i DDL/DML-e ? Nie znam takich (dobrych).

Pozatym istnieje takie pojęcie jak branch i merge.
Pracuje od dłuższego czasu stosując takie rozwiązania przy na prawdę ogromnych systemach i nie miałem jak do tej pory większego problemu z wersjonowaniem.

Ok, w naprawdę wielkich systemach (i naprawdę bazodanowych) pewnie to się sprawdza. Po prostu to 99% kodu ląduje w procedurach składowanych i już.
Tyle, że wtedy pewnie problemem się staje wersjonowanie narzędzi/serwisów pomocniczych, napisanych w czymś innym.

P.S Co do debugowania to fakt jest legendarne i niestety wyprzedza często legendy o sobie :)

Nawet jeśli wyprzedza, to chyba nie bez powodu, nie?

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Od1 - Dla własnych "domowych potrzeb" używam SVN do JAVA i DDL/DML i spisuje się bardzo dobrze, koniec końców to pliki tekstowe.
W pracy mamy nasz system, który również daje sobie radę.

Od2 - jak wyżej. A umieszczanie 99% logiki biznesowej po stronie bazy ma ogromne zalety.

Od3 - powodem tego jest brak wbudowanych mechanizmów, które zawsze w prosty i szybki sposób można sobie stworzyc.Michał Bożek edytował(a) ten post dnia 20.10.10 o godzinie 15:25

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Michał Bożek:

/.../

Co do danych to zwykle się dokłada nie zabiera(najwyżej nie używa)

Tutaj dodam jedną jeszcze rzecz: rzeczywiście, w dużych systemach, pewnie 10MB w tą czy w tamtą nie ma znaczenia. Zupełnie inaczej wygląda sprawa np. w systemach mobilnych, pracujących na "cienkich" platformach posiadających mało zasobów. Tam usunięcie kolumny może mieć decydujace znaczenie.

Tak więc nie jest do końca prawdą, że w trakcie customizacji oprogramowania nie usuwa się danych.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Głudkowski:

Michał Bożek:

/.../

Co do danych to zwykle się dokłada nie zabiera(najwyżej nie używa)

Tutaj dodam jedną jeszcze rzecz: rzeczywiście, w dużych systemach, pewnie 10MB w tą czy w tamtą nie ma znaczenia. Zupełnie inaczej wygląda sprawa np. w systemach mobilnych, pracujących na "cienkich" platformach posiadających mało zasobów. Tam usunięcie kolumny może mieć decydujace znaczenie.

Tak więc nie jest do końca prawdą, że w trakcie customizacji oprogramowania nie usuwa się danych.

W trakcie poważnych customizacji zmieniają się nie tylko kolumny ale i lista tabel i modułów.

Osobiście ciekaw jestem czy są takie systemy gdzie 99% logiki jest w DBMS-ie.
I jaka jest rotacja programistów pracujących przy takim systemie...Piotr Likus edytował(a) ten post dnia 20.10.10 o godzinie 20:18

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Michał Bożek:
1) Oracle + SQL+ PL/SQL + Pro*C
2) PostgreSql + SQL + PL/PGSQL

I najważniejsze to natłuc sobie do czaszki, że baza po to ma możliwość trzymania pakietów i procedur/funkcji żeby z tego korzystać jak najwięcej i jak najczęściej i logikę biznesową liczyć właśnie z pomocą bazy a nie warstwy do tego nie odpowiedniej. Bo po to tyle się płaci za licencję i po to kupuje się szybkie maszyny pod serwery DB żeby miały co robić a nie całe życie select, update, insert bo instalacja Oracla po to żeby trzymać w nim dane tylko to jak spuścić bombę atomową żeby zabić jednego komara.

Pozdrawiam Michał.

Nie zdarma mamy standardy "cienki" i "gruby" klient, w zależnosci od tego co baza ma robić wybiera się optymalne rozwiązanie. Z praktyki dla zaawanoswanych działań na bazie (duży ruch z dużą ilością insertów, update) nie da się oprzeć 99 % logiki na bazie, choćby ze względu na utrudnioną kontrole transakcji (również debagowaniem procedur składowanych). Poza tym nie spotkałem się z rozwiązaniem (być może za krótko się tym zajmuje:)), gdzie 99% jak piszesz logiki załatwia baza.

pozdrawiam

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Likus:

/.../

W trakcie poważnych customizacji zmieniają się nie tylko kolumny ale i lista tabel i modułów.

Dokładnie :)

Osobiście ciekaw jestem czy są takie systemy gdzie 99% logiki jest w DBMS-ie.
I jaka jest rotacja programistów pracujących przy takim systemie...

Może system jest sprzedawany razem z programistami? :)

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Wolański:

Borys M.:
- IBM DB2 UDB - wielki przegrany, potomek pierwszej relacyjnej bazy danych na świecie (System V), obecnie trochę niszowy, ale o ogromnych możliwościach i też w lekkiej wersji darmowej, można posadzić go na prawie każdym systemie, łącznie z Mainframe.

- Informix - drugi zapomniany, który jednak nie dał się wypchnąc przez DB2,
a ostatnio nawet pojawiły się nowe wersje.
Co ciekawe IBM Informix Innovator-C darmowy (do 4 rdzeni/2GB RAM/bez limitu wielkości bazy)

http://www.ibm.com/developerworks/data/library/techart...

O Informix to wolałem już nawet nie wspominać ;)
Bardzo dobry RDBMS i przyjemny, kiedyś popularny, ale totalnie zapomniany, bo zjedzony przez Oracle Database i MS SQL Server.
Nie wiem kto oprócz dawnego Prokom a obecnego Asseco wdrażał na nim systemy w Polsce. Mało chyba kto.
Nie wiem jakie IBM miał początkowe plany jak przejmował Informix. Mi się wydawało, że przeniesie najlepsze cechy Informix do DB2, wprowadzi jakiś tryb zgodności DB2 z dialektem i sposobem zachowania Informix i powoli pogrzebie Informix zupełnie. Kilka lat później, przy okazji centralizacji baz PZU, okazało się, że Informix ma się jednak nad wyraz dobrze i jest ciągle jak najbardziej oferowany - i może o to chodziło, aby jedynie przejąc klientów i może coś w środku usprawnić i ujednolicić między DB2 a Informix, aby zredukować koszty rozwoju.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Duże bazy tak jak ta w KSI ZUS to maja ~40TB są postawione na DB2 OS/390, albo jakimś nowszym. Tam niektóre tabele mają naście miliardów (nie milionów) rekordów i mówię z doświadczenia, że nie robi się tymi tabelami żadnych join'ów, a cały model jest silnie zdenormalizowany. Oczywiście używanie statycznego SQL jest tu kluczowe, choć ostatnio słyszałem, że znowu ożyło dynamiczne preparowanie zapytań (ale nie lamerskie wklejanie stringów wartości w zapytanie) w tym projekcie (może nowa wersja DB2 coś usprawniła). Oczywiście nie używa się tu żadnych procedur wbudowanych (bo to ryzyko dla wydajności i stabilności maszyny na której jest sam silnik bazy), tylko stawia się obok silne maszyny z menadżerami transakcyjnymi połączone po SNA (a nie TCP z uwagi na mniejsze paczki i mniejszy lag), które stanowią middle tier z usługami będącymi ekwiwalentem procedur składowanych. Kod ESQLC (Embedded SQL in C), w tórym się to implementuje, wygląda w ogólnej strukturze podobnie do 4GL takiego jak np.: PL/SQL.

Z zupełnie innej beczki w innym projekcie jest baza 1-2TB postawiona na Oracle RAC i tam jak najbardziej jest ORM ;) , tylko że nie jest to żaden Hibernate, tylko sprawdzona implementacja JDO, która potrafi łyknąć automatycznie generowane zapytania strukturalne ze złączeniami z co najmniej nastu obiektów, generując SQL ze jeszcze większą ilością złączonych tabel i wszystko jakoś działa (oczywiście po optymalizacji i małej denormalizacji miejscami), a do tego tę bazę spowalnia jeszcze replikacja. Jak widać nawet z ORM da się w przypadku tak dużego systemu. Baza ma z ~500 tabel - nie wyobrażam sobie zrobienia szybko takiej aplikacji i jej rozwoju, rzeźbiąc SQL'ami w czystym JDBC - nikt by nie był w stanie tego przetestować, po drobnych zmianach modelu encji.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Likus:

Osobiście ciekaw jestem czy są takie systemy gdzie 99% logiki jest w DBMS-ie.
I jaka jest rotacja programistów pracujących przy takim systemie...Piotr Likus edytował(a) ten post dnia 20.10.10 o godzinie 20:18

Tak na 100% są takie systemy, słyszałem kto taki przykładowy system rozwija, ale nie wiem dokładnie dla kogo - sam nawet chciałem kiedy taki system w ten sposób implementować. Cały KSI ZUS jest tak napisany o ile przyjąć, że usługi z ESQLC na middle tier jest ekwiwalentem procedur składowanych.

Mimo wad, to wbrew pozorom ma też wiele zalet:
- kod biznesowy w takim PL/SQL można poprawić b. szybko bez redeploy aplikacji, a co więcej można łatwiej wersjonować (co jest wymogiem SOA),
- kod biznesowy i sam dostęp do danych może być skutecznie chroniony przed innymi, mniej zaufanym developerami,
- zyskuje się dużą szybkość takiego rozwiązania (jedno wołanie usługi może zasilić całą złożoną formatkę), co ma znaczenie także w systemach drążących/analizujących dane,
- mając procedury składowane można zastosować metodykę SOA, która wpłynie pozytywnie na rozwój takiego projektu,
- aby wymusić pewne wzorce tworzenia procedur/funkcji składowanych jako usługi w sensie SOA, można posiłkować się generatorem kodu (szkieletu usługi),
- rysuje się wyraźny podział na warstwę logiki i prezentacji implementowanej już na jakim WS/AS (jak np.: httpd+PHP, Tomcat, GlassFish, lub IIS, etc), a co za tym idzie można UI rozwijać w innej lokalizacji, w różnych technologiach i kontraktowcami.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Głudkowski:

Ok, a czy są dobre narzędzia, którymi jednocześnie mogę wersjonować i kod aplikacji (np. w C#), i DDL/DML-e ? Nie znam takich (dobrych).

To jest akurat proste.
Tworząc system, masz zwykle drzewiastą strukturę plików źródłowych najczęściej z podziałem na kod głównego języka programowania, kod różnorakich zasobów, kod technologi XML'owych - jak jak się to zwykle robi np. używając Maven 2/3. DML'e i DDL'e można umieścić z innymi zasobami, a co więcej w trakcie kompilacji można je automatycznie wykonywać na bazie developerskiej - trzeba skonfigurować odpowiedni krok/pugin. Całość tej struktury można wersjonować dowolnym system kontroli wersji jak np. SVN, czy HG (mówię tu o tych najlepszych).

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Drobne wyjaśnienie: w przypadku wersjonowania usług w odniesieniu do SOA, miałem na myśli nie wersjonowanie kodu usług, ale tworzenie oddzielnych wersji usług dla zapewnienia zgodności wstecznej z już istniejącym kodem warstw wyższych.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Piotr Głudkowski:

Piotr Likus:

/.../

W trakcie poważnych customizacji zmieniają się nie tylko kolumny ale i lista tabel i modułów.

Dokładnie :)

Osobiście ciekaw jestem czy są takie systemy gdzie 99% logiki jest w DBMS-ie.
I jaka jest rotacja programistów pracujących przy takim systemie...

Może system jest sprzedawany razem z programistami? :)

:)
U kilku klientów, którzy żonglują dostawcami oprogramowania, obserwuję takie zjawisko, które głównie objawia się tym, że ludzie zmieniają pracodawcę na tego co przejmuję pałeczkę u klienta, by pozostać przy "swoim" systemie lub technologi, które to ma ten jeden klient. Słyszałem też o próbach kupienia całego działu w takich sytuacjach, ale nie wiem czy często jest to finalizowane.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Wszyscy piszecie o tym co jest lepsze lub gorsze technologicznie, a ja bym do tematu podszedł raczej z innej strony. Patrząc długoterminowo pod kątem dostępności pracy i wysokości pensji to w Polsce zdecydowanie najlepiej wypada Oracle.
Wystarczy w dowolną wyszukiwarkę pracy wpisać Oracle, DB2 i SQL Server żeby sie zorientować w co warto inwestować swój czas.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Przemysław R.:

Łukasz Dudek:

Da się zrobić wiele choć niektóre sprawy wymagają więcej pomysłowości.

Można ściąć drzewo kamienną siekierką , tylko pytanie po co?

może ktoś lubi odciski :)

wracając do meritum MySQL do baz danych ma się tak samo jak maluch do samochodów. brakuje mu wiele do bycia bazą danych pełną gembą mi np. robienia backupów z poziomu bazy danych

No i tym razem się również mylisz, backupy oczywiście są.

Temat: MySQL vs PostgreSQL vs Oracle vs Other...

Artur Mucha:

Przemysław R.:

Łukasz Dudek:

Da się zrobić wiele choć niektóre sprawy wymagają więcej pomysłowości.

Można ściąć drzewo kamienną siekierką , tylko pytanie po co?

może ktoś lubi odciski :)

wracając do meritum MySQL do baz danych ma się tak samo jak maluch do samochodów. brakuje mu wiele do bycia bazą danych pełną gembą mi np. robienia backupów z poziomu bazy danych

No i tym razem się również mylisz, backupy oczywiście są.

podaj magiczne polecenie SQL do wykonania backupu bazy MySQL coś ala

BACKUP DATABASE [AdventureWorks] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\AdventureWorks.bak' WITH NOFORMAT, NOINIT,  NAME = N'AdventureWorks-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10