Sorry, ale produkt który:

– nie zapewnia ACID

– "po cichu" obcina dane wejściowe jeśli są za długie w stosunku do długości pola (poprawili to już?)

– nie posiada obsługi subselectów, skutkiem czego wiele aplikacji zamiast nich musi wykonywać wielkie joiny

– nie posiada obsługi stored procedures i prepared statements skutkiem czego mamy trwającą do dzisiaj epidemię bugów SQL injection na stronach WWW

nie nadaje się absolutnie do niczego. Owszem, większość tych rzeczy zaimplementowano w MySQL 5.0 i ta seria już się do czegoś nadaje. Tylko, że właśnie ogłoszono, że te właśnie ficzery – które powodują że MySQL zaczyna wreszcie przypominać bazę danych – mają być opcjonalne, czyli praktycznie wyrzucone. Inaczej mówiąc, to jest powrót do MySQL 3.x. Jak mawiał Lenin – "jeden krok w przód, dwa kroki w tył".

Ja o tym wiem. Ale to wcale nie jest dobre.

Jeśli (np.) integralność jest opcjonalna, to deweloper ją sobie wyłączy, bo będzie mu się wydawać, że jest niepotrzebna. Potem wytworzy aplikację która z załączoną integralnością działać nie będzie. Więc użytkownik też będzie sobie musiał to dla kompatybilności wyłączyć. Efekt jest taki sam jak wyrzucenie ficzera.

Jest wystarczająco za dużo złego kodu PHP/MySQL i wystarczająco dużo niedouczonych programistów tego środowiska żeby jeszcze zwiększać w tych narzędziach możliwości zrobienia sobie krzywdy.

To się nie powinno nazywać Drizzle, tylko Retro 🙂

Choć i mnie denerwowało zawsze że MySQL tylko bazę danych przypomina, to czy tak naprawdę do aplikacji webowych, szczególnie prostszych, jest potrzebna Relacyjna Baza Danych z Prawdziwego Zdarzenia?

Mnie uczono, że powinno się jak największą ilość przetwarzania danych przerzucać na bazę, aby (1) zmniejszyć ilość przesyłanych danych do i z bazy i (2) dać pole do popisu optymalizatorowi zapytań.

Nieszczęście pt. MySQL polega na tym, że powstała duża grupa ludzi, którzy uważają, że "zaawansowane" ficzery nie są potrzebne, bo oni nauczyli się przez lata radzić sobie bez nich. Problem polega na tym, że bez tych "zaawansowanych" ficzerów to prościej i szybciej byłoby użyć SQLite, BerkeleyDB czy nawet plików tekstowych.

– baza danych jako kontener przechowujacy dane/pilnujacy ich spojnosci

Ba, tylko że MySQL nawet spójności danych pilnować nie potrafi.

Ogólnie, to nawet jestem w stanie się z takim podejściem zgodzić. Natomiast nawet ono nie jest dla mnie w stanie usprawiedliwić stosowania czegoś w stylu MySQL 3.x.

hmm to powyższe dotyczyło informacji o braku obsługi transakcji.. chyba źle kliknąłem w "Odpowiedz". Transakcje są,ale nie w domyślnym silniku MyISAM, tylko innoDB (pozostałych tak naprawdę nie znam, nie używam). Niestety osobiście stwierdzam, że mają słabą obsługę lock – używałem i tak uważam. Podobno istnieją bazy danych, które potrafią podać jaki użytkownik zablokował daną komórkę, lecz nie wiem jakie:)

To by się przydało, przez to muszę robić dodatkowe pola w tabeli z datą i nazwą użytkownika – tego naprawdę mi brakuje:(