Po miesiącach ciężkiej pracy, zespół deweloperów najbardziej zaawansowanego systemu zarządzania relacyjnymi bazami danych, PostgreSQL, wydał wersję 9.0 swojego produktu. Hitem jest binarna replikacja, ale nowych funkcji mamy o wiele więcej.
W PostgreSQL 9.0 znajdziecie więcej nowych ważnych funkcji niż jakiejkolwiek wcześniejszej wersji. Programiści do najważniejszych nowości zaliczają:
– hot standby (funkcja podobna do Oracle’s Active DataGuard)
– streaming replication – asynchroniczny mechanizm replikacji (w tym DDL) wbudowany jest teraz w Postgresa
– in-place upgrades
– wersję dla 64-bitowej wersji Windows
– proste zarządzenia uprawnieniami (masowa aktualizacja)
– anonimowe bloki i nazwane parametry w procedurach składowanych
– nowa opcja dla window functions o których pisał depesz w notce Waiting for window functions
– sortowalne agregacje
Szczegółowe omówienie zmian znajdziecie w przewodniku po PostgreSQL 9.0.
Postgresa 9.0 ściągnąć możecie ze strony produktu lub przez Wasz ulubiony system zarządzania pakietami, jeśli jesteście użytkownikami Linuksa bądź BSD.
zmienilo sie na prawde sporo i bardzo szkoda ze do nowego debian stable (czyli obecnie zamrozonego squeeze) nie wejdzie ta wersja :/
pewnie w backportach będzie.
Nie rozumiem tego żalu, albo używasz sprawdzonego oprogramowania bo potrzebujesz pewnej platformy albo uganiasz się za nowościami. Nikt kagańca ci nie założył.
Jeżeli jesteś już w stanie użyć nowych funkcji to samodzielne skompilowanie postgresa na swoje potrzeby nie powinno być wyzwaniem. Bo raczej nie ma jeszcze oprogramowanie zdolnego z nich korzystać.
W przeciwnym wypadku co za różnica jaką wersję masz w paczkach. Stara działa źle, bądź jest dziurawa?
Zawsze możesz zmienić na Opensuse, wydali juz 17 września.
Postgres to swietna baza szkoda tylko, ze nie ma takiej wersji lite na male urzadzenia bez zaawansowaych funkcji, ale latwo przenoszalne na pelnego postgresa.
Pytam, bo naprawdę nie wiem – a jest jakaś inna taka baza (porównywalna do PostrgreSQL)?
znaczy się w sensie taka mała z możliwościami postrgresql? Nie no wiadomo że nie. Jest sqlite z tego co wiem to oprócz pc np. na android działa.
SQLite jest integralnym elementem calej masy rzeczy, chociazby iOS-a.
Źle to ująłem – inna umożliwiająca takie łatwe przenoszenie do pełnego Postgresa. Bo pewnie przenieść się da z każdej ale nie obejdzie się bez modyfikacji SQL, skoro ma być „bez zaawansowanych funkcji”.
Nie ma, ale w czasach chmur, oczyma wyobraźni widzę że na małych klientach będą tylko biblioteki do łączenia się z bazą, sama baza będzie „gdzieś, tam”..
Mi w postgresie brakuje tylko czegoś w stylu sqlitowego fts. Wtedy to byłby hit, a tak to musze je używać zamiennie, w zależności od potrzeb…
wspomniany przez trasza ios składuje np notaktki w sqllicie. Zapotrzebowanie na lekkie bazy jest i bedzie
SQLite jest wszędzie, o ile mnie pamięć nie myli jest w iOS, Androidzie, Firefoksie, Google Chrome, WebKicie, OSX…
Co jest, tak btw, slicznym przykladem, dlaczego nie nalezy uzywac licencji GPL – gdyby SQLite byl na GPL, nie moglby byc uzywany w zadnym z w/w zastosowan.
Używanie GPL do bibliotek jest wyjątkowo głupie i nawet FSF to kiedyś zauważało, przez co powstała licencja LGPL.
Sytuacja mogłaby wyglądać inaczej w przypadku aplikacji dla końcowego użytkownika.
Nie, FSF nadal uwaza, ze GPL dla bibliotek to dobry pomysl. Za GPL FAQ: „Using the Lesser GPL for any particular library constitutes a retreat for free software. It means we partially abandon the attempt to defend the users’ freedom, and some of the requirements to share what is built on top of GPL-covered software. In themselves, those are changes for the worse.”
No przecież napisałem że kiedyś uważało.
Swego czasu użycie LGPL dla bibliotek było uważane przez FSF za pewien rodzaju kompromis. W pewnym momencie jednak zreflektowali się i stwierdzili jednak że LGPL przynosi więcej strat niż zysków, co zaowocowało zmianą stanowiska na zacytowane. Tak przynajmniej ja to pamiętam.
@el.pescado: Moze jednak przeczytaj to, co zacytowalem. FSF _nadal_ uwaza, ze LGPL dla bibliotek to krok wstecz.
A co ja napisałem?
Wczoraj rano miałem ściągnąć RC1 a tu taka miła niespodzianka.
Ciekawe, czy planner zapytań radzi sobie w końcu z podzapytaniami skorelowanymi. Ktoś wie?
a jaki miał wcześniej problem z tym?
Miał. Robił je w sposób naiwny – tj. w ciemno zamieniał na zagnieżdżone pętle. Co w 99% przypadków oznaczało konieczność ręcznego przepisania zapytania, żeby mieć akceptowalną wydajność.
A ja jestem ciekaw czy dziedziczenie tabel i kluczy z nadrzędnych zostało poprawione? To był zawsze problem.
Ale po co jak jest Oracle?
Ale po co Oracle jak jest PostgreSQL?
A po co cokolwiekSQL jak jest MySQL ?
bo mysql ma do d. licencje do zastosowań komercyjnych, i całkiem do niedawna nie wspierał nawet transakcyjności (wersja 4).
@tomaszkubacki
c-c-combo breaker!
😛
Po co jakakolwiek baza danych skoro dane można trzymać w plikach tekstowych?
Po co pliki tekstowe jak można zapisać na kartce?
Po co zapisywać na kartce, jak można zapamiętać? Mózg ma ponoć 10^18 połączeń czy jakoś tak…
Po co mózg, jak jest rejestr Windows?
Kartki i mozg ludzki nie pasuja do tej przepychanki. O ile pliki tekstowe mozna udostepnic do zapisu i odczytu dla wielu osob, to z informacjami na kartkach papieru jest juz problem, bo ktos musialby to nadzorowac i segregowac. Nie mowiac juz o ludzkim mozgu – wprawdzie dostep do tych samych danych mogloby miec kilka osob jednoczesnie, ale juz do roznych musieliby czekac w kolejce. Tak samo w przypadku zapisywania. I pozostaje jeszcze sprawa backupu i przywracania poprzednich wersji:)
Ale po co Oracle jak jest MS SQL?
bo mimo, że MS SQL jest obecnie świetną bazą danych do wiekszości zastosowań to przy Oracle sie umywa.
Nie każdy potrzebuje Oracle. Po co mi Oracle jeżeli wystarczy mi Postgres?
Druga kwestia, że nie kazdego stac na oracle
Stać każdego, bo fajnie rozwiazne jest to licencyjnie i za ta sama kase w oracle dostaje sie wiecej
Za tĘ samą kasę tzn. za darmo w Oraclu NIE dostajemy więcej, wręcz znacznie mniej.
@pytong: Kompromitujesz się.
wybacz mu koło oracla raz stał 😉
Poldek, nie pierwszy to raz i zakładam, że nie ostatni, kiedy to pytong się kompromituje. Skoro lubi…
Nikt mający blade pojęcie o temacie nie mógł napisać czegoś takiego, mam 100% pewność że trollujesz. Co chcesz porównywać z Postgresem? XE czy 11g?
zawsze patrzyłem na ludzi używających Oracle jak na dziwolągów 😛
Czy in-place upgrades znaczy, iż wreszcie Postgresql będzie potrafił zaktualizować swoje bazy po zmianie binarek na nowsze?
Przyznam, że hocki-klocki z backupem przed i restorem po są rzeczą, która odrzuca mnie od niego na odległość i powoduje problemy gdy DBA!=SYSA.
Tak. Od tej wersji można robić upgrade w miejscu z wersji 8.3 do 9.0 i 8.4 do 9.0
Nie można. Będzie informacja że bazy zostały utworzone na wersji 8.x i się nie odpali.
Można, tylko trzeba odpalić program do migracji z contrib’a.
czyli jednak nie można – trzeba użyć dodatkowego programu
http://www.youtube.com/watch?v=EcKGq7lh8Ww
Dziękuję, ale niestety właśnie z pg_migratorem miałem problemy. Nie potrafiłem go zmusić, by przekonwertował bazy do wersji 8.4 (z 8.3). Dlatego też upewniam się, czy w wersji 9.0 działa to bezproblemowo w każdej konfiguracji.
W wersji 9.0 do contrib doszedł pg_upgrade, a to jest ten sam pg_migrator właśnie, więc żadnych rewelacji nie oczekuj – albo to usprawnili, albo nie.
Trochę poprawnili, ale w dalszym ciągu nie można przekonwertować pól zawierających indeksy do ft.
A ja tam od czasu gdy poznałem CouchDB sram na to całe SQL i współczuję ludziom, którzy z tych czy innych względów muszą się ciągle w tym bałaganie babrać.
Owszem to nie są to wymienne technologie, ale też SQL jest zwyczajnie mocno przereklamowany i podejrzewam, że w wielu zastosowaniach szybko zostanie wyparty przez dojrzewające właśnie rozwiązania NoSQL. Map/Reduce rządzi ;).
Tyle ze MapReduce jest do innych zastosowan. A poza tym sie zgadza, tam gdzie jest sens stosowac MapReduce nie ma sensu uzywac bazy SQL 😉
Ostatnio i Big Table rządzi, ale raczej nie zastąpi wszędzie SQL. CouchDB nie nadaje się do części zastosowań, o ile pamiętam ma za wolne inserty.
Mi w zasadzie jest obojętne jaka jest baza, bylebym miał interfejs obiektowy do bazy.
Rozwiązania NoSQL właśnie dlatego tak zyskują obecnie na znaczeniu, że są dużo szybsze od ich SQL-owych odpowiedników, tam gdzie nie potrzeba zbytniej normalizacji danych, czyli gdzie nie ma dużej redundancji bez wprowadzania odrębnych kategorii danych w osobnych tabelach.
Oczywiście nie wszystko da się w ten sposób efektywnie (objętościowo) zamodelować i tam SQL wciąż ma pozycję niezagrożoną.
Ja z kolei współczuję ludziom, którzy muszą pracować z danymi nadającymi się do trzymania w CouchDB.
Oracle od bodaj wersji 9 ma coś, co nazywa „support for unstructured data”…
Widzę, że potwierdza się stara prawda, że jak ktoś czegoś nie rozumie i nie chce zrozumieć, to krzyczy, że jest do dupy, w sumie przykre.
CouchDB, fajne rozwiązanie, o ile nie przeszkadza, że czasami giną dane, że nie ma transakcji, że nie ma schematu danych, więc i ograniczeń żadnych nie ma. W efekcie dane mogą się ładnie rozjechać (co wiele razy widziałem) i za jakiś czas można sobie bazę zaorać i jest przykro. Oczywiście potem się obwinia za to bazę, a nie programistę.
SQL potrafi być bardzo wydajny, dane nie giną ot tak, mogą być spójne i nie wyobrażam sobie wielu systemów bez dobrze zrobionych struktur danych, czego np. w CouchDB nie uświadczysz, bo tam, chociażby przez głupi błąd programisty, można tak namieszać, że potem się danych nie poskłada. To jest coś, czego np. w Postgresie można prosto uniknąć.
Ech, aż sam się sobie dziwię, że odpisuję komuś kto reprezentuje taki poziom w pierwszym chociażby zdaniu, jak się cieszę, że razem nie pracujemy, kultury więcej może.
map/reduce świata nie zbawi, ale istnieją nierelacyjne bazy z obsługą transakcji: http://ravendb.net/
A fuj 😛
+1
Ode mnie też +1. 🙂
@szymon
Kolega widzę bardzo zasugerował się bugiem w wersji 1.0 o którym autorzy ostrzegają wyraźnie na swojej stronie. Poza tym – co jak co ale akurat CouchDB w erlangu (nie przypadkowo właśnie w tym języku – poczytaj o genezie tego wyboru, początkowo był pbwiem w C++) z przeźroczystą replikacją, wykrywaniem konfliktów i równoległością „z definicji” jest dużo pewniejszym rozwiązaniem niż większość SQL-owego softu z zabugowanym na potęgę Oracle na czele.
Co do schematów, zafiksowanych struktur danych itp. jest to dokładnie ta sama sytuacja, jak ta w sporze między językami z typowaniem statycznym i dynamicznym. Obydwa podejścia sprawdzają się lepiej w różnych sytuacjach. Nie przez przypadek serwisy webowe są tworzone właśnie w tych drugich, z bazami już teraz widać, że zaczyna być podobnie.
SQL potrafi być szybki? Proszę mnie nie rozśmieszać. To właśnie wciąż raczkująca akademicko teoria mnogości i jej nierozwiązane problemy sprawiają, że SQL wciąż jest problemem optymalizacyjnym. Dość powiedzieć, że to samo zapytanie potrafi się zachowywać skrajnie różnie na różnych RDBMS-ach.
MapReduce jest prosty w koncepcji, łatwy w implementacji i co najważniejsze sensownie można oszacować wydajność zastosowanej strategii wyszukiwania wyniku. Z SQL-em można w tym względzie jedynie eksperymentować, bo tu jest jedno wielkie voodoo o jakim pojęcie mają jedynie autorzy danego silnika SQL-owego (a i Ci nierzadko do końca wszystkiego nie ogarniają).
Jak napisałem na samym początku. Nie uważam tej koncepcji za konkurencję dla relacyjnych baz danych a jedynie jako sensowne rozwiązanie dla sytuacji, w których SQL zwyczajnie się nie sprawdza, choć dotychczas był jedyną powszechnie znaną alternatywą, stąd jego popularność.
Do dużej części zastosowań webowych, gdzie informacje są mało wzajemnie redundantne (w senie ich budowy, nie znaczenia) i liczy się przede wszystkim ich szybka prezentacja, rozwiązania NoSQL (nie koniecznie tylko CouchDB) nadają się dużo lepiej niż sztywne założenia baz SQL-owych.
Wypowiedź kolegi miała mało wspólnego z „bugiem w wersji 1.0”.
SQL mało wydajny? SQL potrafi być bardzo wydajny, tylko że wymaga zmiany myślenia. Myślenie na poziomie relacji i obiektów to zupełnie inne przestrzenie. Nie raz widziałem jak programista projektował bazę w oparciu o obiekty … nigdy nie wychodziło z tego nic dobrego. Naucz się teorii baz danych i dowiedz sie jak pracują silniki bazodanowe, bo było już kilka benchów gdzie SQL wcale nie odstawał od NoSQL’a (a wcale nie były to benche typu SELECT * ). Za kilka lat ci którzy teraz sie rzucili na NoSQL bedą wracać do rozwiązań SQL.
SQL jest dużo bardziej elastyczny niż specjalizowane bazki obiektowe.
„Nie przez przypadek serwisy webowe są tworzone właśnie w tych drugich”, o ile wiem najpopularniejszy jezyk webowy PHP coraz bardziej idzie w kierunku statycznego typowania.
@wojtekm: zastosowania dla baz klasy NoSQL to ja widzę w przypadkach typu semantic web/ontologie czy jakieś sieci neuronowe. I akurat serwisy webowe są idealnym przykładem patologicznym – większość jest tworzona przez ludzi, którzy nie powinni mieć kontaktu z komputerami, stąd popularność choćby MySQL. Osoba na odpowiednim poziomie niekompetencji zamiast prawidłowej reprezentacji danych niech sobie faktycznie weźmie jakiś silnik w postaci 'worka danych’.
Największe trudności w SQL sprawia szeroko pojęty load balancing/HA (tworzenie clustrów, replikacje itp.). Niestety tak się składa, że ZAZWYCZAJ gdy zachodzi potrzeba zastosowania takich mechanizmów, dane akurat pasują pod SQL. Wyjątkami są tutaj może systemy facebooka czy googla, bo tam jednoznaczność zwróconych danych nie jest krytyczna.
+1 dla gotar 🙂
@ak47 O ile wiem PHP mocno ostatnio traci na rzecz Ruby’ego i Pythona. A propos „myślenia obiektowego”, czy to nie „mapowanie obiektów na SQL” i „automatyczne migracje schematów” są teraz takie trendy? Wygląda na to, że świat webowy się uparł, żeby zrobić bazom SQL na złość.
Co do problemów z utratą danych – link albo sprawa nie istnieje.
Na takim poziomie ogólności mogę jedynie stwierdzić podobnie, poczytaj o skalowaniu/równoległości i jeszcze raz przemyśl swoją wypowiedź.
Problemem baz SQL-owych, jak słusznie zauważa niżej @gotar jest skalowanie. Po prostu MapReduce jest skalowalne „by design”, SQL nie – co więcej, bardziej zależy od schematu bazy niż samego silnika. Z im większą skalą będziesz miał do czynienia, tym bardziej będziesz musiał się z tym liczyć.
Z resztą co ja będę się tłumaczył, swego czasu była tak wyszukiwarka Altavista – ktoś jeszcze pamięta? Jej autorzy chwalili się, że działa w oparciu o 4 superkomutery z SQL-ową bazą i jest to demon wydajności.
Przyszedł wujek Google ze swoim MapReduce i klastrem tanich pecetów i pozamiatał. Dlaczego nie użył klastra z bazą SQL-ową? Pytanie retoryczne.
O tym piszę i do znudzenia przypominam, że nie uważam rozwiązań NoSQL (zresztą to bardzo szerokie pojęcie) za alternatywę dla SQL-a, tylko za wypełnienie tej luki, do której zwyczajnie SQL w dużej skali się nie nadaje.
Jedyne o czym możemy dyskutować to na ile owa luka jest duża. Moim skromnym zdaniem jest dość znaczna – z tym można polemizować, to jedynie moje zdanie.
Ostatecznie, co mnie bardzo cieszy, coraz bardziej zaczyna być podnoszona w informatyce kwestia istotności postaci i sposobu przetwarzania danych, a nie tylko kodu, który to realizuje. Data Driven Programming zaczyna być brany pod uwagę przez coraz większą rzeszę deweloperów i to nie tylko tych, od gier i silników graficznych, choć tu ta tendencja jest obecnie chyba najbardziej zauważalna. Metodologia jest jednak uniwersalna i w takim samym stopniu dotyczy programowania dla wielu rdzeni co dla wielu hostów.
Tu jest właśnie całe clou problemu – czy da się efektywnie zamodelować (reprezentować) i przetwarzać określone dane w modelu relacyjnym czy bardziej efektywna jest ogólnie pojęta struktura puli. Odpowiedź będzie zależeć od wielu czynników, w tym skali.
Ja się cieszę, że jest wybór. Jeśli komuś przeszkadza, że jego „kanoniczne SQL-owe widzenie świata” zostało zaburzone, „bo to wszystko przez debili, którzy się nie znają na programowaniu” to już niestety jego problem.
Zdajesz sobie sprawe, ze MapReduce wcale nie jest uzywany przy wyszukiwaniu? MapReduce jest na to zbyt wolny.
MapReduce to oczywiście metodologia postępowania z danymi. Wyszukiwanie zazwyczaj odbywa się w zaindeksowanych zbiorach już stworzonych przy pomocy różnych zdefiniowanych funkcji map(), reduce() i pośrednich.
Akurat jeśli ograniczysz się do pewnego podzbioru funkcjonalności baz relacyjnych równoważnego z tym, co oferują bazy NoSQL (np. proste mapowanie klucz-wartość), to relacyjne skalują się równie dobrze. Implementacja czegoś w rodzaju BigTable na silniku relacyjnym też jest możliwa bez większej trudności. Tylko że silnik relacyjny to overkill na to. Problem jest w tym, że to nie same bazy relacyjne się „trudno” skalują, tylko wszelkie złożone modele danych (gdzie są nietrywialne zależności między danymi + wymaganie transakcyjności + spójności + konieczność wykonywania szybkich, złożonych zapytań). To co w relacyjnych bazach jest trudne, w NoSQL jest z definicji niemożliwe.
Jak napisał gotar, NoSQL jest świetne do systemów eksperckich wykorzystujących ontologie, wnioskowanie rozproszone itp, bo tam się zakłada, że będzie pewien niezerowy odsetek pomyłek i spójność nie jest priorytetem. Do normalnych aplikacji webowych, to krok wstecz.
@Królik: ale w tym zakresie danych, gdzie RDBMS-y skalują się równie dobrze nie ma przeciwwskazań dla NoSQL, tak? No to nie krok wstecz a naturalna ewolucja, bo bazy zorientowane na dokumenty lepiej mapują się do obiektów – a w aplikacjach webowych dominują języki obiektowe – niż bazy relacyjne.
@wojtekm
php traci na rzecz rubego i pythona. Ale powód jest zupełnie inny prostota, narzedzia i spójność (ale np facebook jest w php i wiele innych duzych serwisów). Tak samo zaczyna tracić java (bardzo statyczna) ale wolniej.
Nikt nie robi na złość bazom relacyjnym, a narzedzia ORM powstały aby ułatwić/przyśpieszyć programowanie programistom obiektowym (o ile proste zapytania się pisze szybciej to skoplikowane częściej szybciej napiszesz używając plain SQL), zmiana języka programowania w trakcie pisania podobno powoduje spadek wydajności. Wiele osób traktuje bazy relacyjne jak worek na dane i nie potrafią a nawet nie chce użyć bazy jako czegoś więcej. Takie podejście jest najgorsze z możliwych, ale niestety i najczęstsze. Wtedy się własnie, w pewnym momencie zaczynają schody, które trudno przejść bez zmian w strukturach danych. Wymaga to osoby z wiedzą, oraz wiele pracy, (nie ma złotej reguły, cała praca wymaga dostosowania struktur do charakterystki, często wymaga rozrzucenie obecnie jednej bazy na wiele baz o różnych charakterystykach), komplikuje to kod i wymusza zmiany. Ponad połowa wydajności rozwiązań opartych o SQL zależy od zaprojektowania struktury, jak tutaj skopiesz bardzo trudno jest coś zrobić wyżej.
W Mapreduce nie ma żadnych ograniczeń aby nodem nie mogła być baza relacyjna, z logicznego puktu widzenia jest to midelware/conector pomiedzy clientem a storagem (nawte chyba robi tylko zapytania RO). Oracle teradata posiadają bardzo podobne technologie (ale to kosztuje sporo pieniędzy).
Co do altawisty uzywałem kilka razy jakoś nie zauważyłem problemów z wydajnością (z tego co pamiętam było przeładowane reklamami).
Gry podobno bardzo intensywnie wykorzystują bazy relacyjne …
„Jeśli komuś przeszkadza, że jego “kanoniczne SQL-owe widzenie świata” zostało zaburzone, “bo to wszystko przez debili, którzy się nie znają na programowaniu” to już niestety jego problem”
Ziew… Tak każdy kto nie podziela twojego punktu widzenia jest debilem itd. Dorośnij.
@ak47
Kończąc już wątek, bo chyba temat został wyczerpany i myślę, że mimo wszystko doszliśmy do jakiegoś porozumienia, chciałbym wiedzieć co konkretnie masz na myśli pisząc: „Gry podobno bardzo intensywnie wykorzystują bazy relacyjne…”?
Osobiście nie znam, chyba że chodzi o jakieś sieciowe „wirtualne światy”, ale to zupełnie inna bajka i szczerze mówiąc nie wiem na czymto stoi.
„Ziew… Tak każdy kto nie podziela twojego punktu widzenia jest debilem itd. Dorośnij.” – przeczytaj dobrze jeszcze raz fragment, który komentujesz, akurat wyraża on mniej więcej Twój komentarz… 😉
Na tym podobno, to jest informacja z 3 ręki, że gry na pc typu wiedźmin itd mają w siebie wbudowany silnik relacyjny.
W repozytoriach to my nowego Postgresa jeszcz przez pare dobrych miesięcy nie zobaczamy jeszcze ;(( A co do CrouchDB, zgadzam się z opinią wojtkam. Staje się to bardzo popularnym rozwiązaniem. W moim przypadku jako dodatek do Ruby ;)))
pozdrwiam
demaio
wojnowski o wordpresie
SPAAAAM! :P.
Powinieneś napisać jakich repozytoriach, bo np. w Archu w testing nowy postgres będzie za max. kilka dni (a rc1 jest w aurze).
Zmień dystrybucję na coś aktualizowanego.
Tak przy okazji, linuks jest fuj bo gpl i zlepek hacków do tego co wydanie zmiana api.
Jednak Postgres jest zajebisty bo licencja pasuje, że do tej pory co wydanie to problem z upgradem, bo format plików się zmienił to jakoś płaczu pewnej osoby słychać nie było:D.
Tak jakby w tym przypadku darowanemu postgresowi w zęby się nie zaglądało 🙂
@bobycob: „Trollować to trzeba umić” (do purystów językowych, w oryginalnym cytacie było „umić”, a nie „umieć”).
Jeśli już chcesz koniecznie coś porównywać, to proponuję PostgreSQL z MySQL. Dwa lata temu był to popularny argument w odwiecznej dyskusji BSD v. GPL, oczywiście na korzyść MySQL ze względu na popularność. Obecnie jednak brakuje śmiałków, żeby użyć tego przykładu w dyskusji.
Czyżby GPL był OK, natomiast GPL od Oracle jest już fuj? Moim zdaniem deweloperzy MySQL sami się załatwili przez chciwość – patrz podwójne licencjonowanie. Oczywiście istnieją forki, tylko który wybrać: Drizzle, OurDelta, Percona Server, a może MariaDB?
Nawet nie będę porównywał tego z rozwojem PostgreSQL, bo to jak kopanie leżącego.
@blinkkin: ale on porównuje nie dwie bazy danych o różnych licencjach, tylko dwa niestabilne API o różnych licencjach. Gdzie np. Edkowi przeszkadza jedynie to z gorszą licencją 😉
@Reddie: Są lepsze powody, żeby pojeździć po FreeBSD 😉
Ale ja nie mam powodu jeździć po BSD. Chciałem tylko wytknąć hipokryzję.
@Reddie: Gdzie w tym przykladzie widzisz jakies niestabilne API?
A MySQL to, swoja droga, sliczny przyklad, jak licencja GPL potrafi zabic projekt. Przed MySQL chyba sie to, w przypadku zadnego duzego kawalka oprogramowania, nie zdarzylo.
@trasz: GPL pogrzebało dietlibc i Newlib – ciekawe alternatywy dla glibc w niektórych rozwiązaniach (szczególnie embedded). Może nie tak duże i znane projekty jak MySQL, ale chyba jeden z „najlepszych” przykładów idiotycznego licencjonowania.
@Edek: tak, czepiaj się semantyki i udawaj, że nie wiesz o co chodzi.
@Reddie: Chodzi o to, ze pare osob, lubiacych pisac subiektywne komentarze, zarzuca mi, ze pisze subiektywne komentarze? ;->
tsh „obiektywność” twoich komentarzy nie pozostawia najmniejszych wątpliwości, szują okazałaby się osobą oskarżająca o stronniczość.
nno chyba, że w przypadku, MacOS, Iphone, BSD, Linuksa, Mysql, Postgres… i całej reszty bo w pozostałych przypadkach na pewno jest niepodważalna. 😀
edek jest niestabilne api, są zmieny miedzy wersjami niekompatybilne wstecz.
8.2>8.3 usuniecie wsparcia dla porównan typu '1′::text=1::int
8.3>8.4 zmiana zachowania truncate dla tabeli dziedziczących (wczesniej czysciło tylko tabele matke teraz czysci wszystko)
i kilka innych
@Edek: nie. O to, że twój subiektywizm jest tak wybiórczy.
@Reddie: Twoj jest wybiorczy w dokladnie takim samym stopniu. Dlatego tak zabawnie brzmi zarzucanie mi hipokryzji w twoim wydaniu – bo jest to hipokryzja. Przez hipokryzje. 🙂
@Edek: no, a teraz dowód. Ułatwię ci sprawę – do udowodnienia, że masz rację, wystarczy przywołanie mojego komentarza – jakiegokolwiek – w którym narzekam na niestabilne API. Też jakiekolwiek.
Powodzenia.
@Reddie: Ech, znowu sie pogubiles. Nikt nie twierdzi, ze jestes subiektywny w dokladnie ta sama strone, co ja. jestes – podobnie jak reszta Linuksowych fanbojow – subiektywny w strone dokladnie odwrotna – piszesz o wadach, realnych lub wyimaginowanych, wszystkiego, co nie jest Linuksem, problemy z Linuksem pomijajac.
@Edek: zwracam uwagę na przedostatnie zdanie mojego komentarza.
@Reddie: W sensie, „Tez jakiekolwiek.”? Niewiele z niego wynika.
@Edek: czytaj i myśl do skutku. Serio, znudziło mi się tłumaczenie ci rzeczy oczywistych 😉