[quote=PaK]Nie wiem czy suchar, bo dawno sie nie udzielałem.
Powstała już niezła “nakładka” na Arel:
http://metautonomo.us/projects/metawhere/[/quote]
Suchar nie suchar, bardzo fajny plugin. Sporo osób nie lubi metod wywoływanych na symbolach i przeciążania operatorów, ale dla mnie to jest bardzo dobry kierunek. Wrzucanie conditions jako stringa daje mniejsze możliwości, a wszelkie potworki jakie do tej pory widziałem np. żeby zrobić OR w hashu, są po prostu nieczytelne.
Dlatego jak widzę taki kod:
def self.published
where(:published => true) | where(:confirmed => true)
to wcale nie myślę: “ojej! oni przecież nadpisali operatory! to jest brzydkie!”, tylko raczej: “wreszcie jakiś ładny kod do formułowania zapytań SQL!”
Przy okazji, jeżeli ktoś nie wie, to taka składnia była zastosowana już wcześniej w DataMapperze i Sequelu (ale nie wiem od którego się zaczęło ;-), więc nie jest to nowość w świecie ORMów rubiowych.
No tak chyba może myśleć tylko zaślepiony Javowiec lub PHPboy (choć ten drugi raczej nie wiem co to operatory ;). Nawet w C++ można było “nadpisywać” operatory, a faktycznie to
definiować dla swoich klas ich obsługę. Operator nie różni się (wiele) od metody i ktoś kto zabrania ich nadpisywania tak samo powinien zabronić nadpisywania metody .to_s “bo przecież ona jest już zdefiniowana”. Możliwość przeciążania operatorów to jedna z ważniejszych cech języka programowania IMHO.
Jest to ten kierunek o którym myślałem kilka miesięcy temu. ARel jako niskopoziomowe API. Pluginy budujace konkretny DSL jako wysokopoziomowe API.
BTW w Sequelu sa chyba 3 sposoby generowania warunków
Chętnie bym usłyszał ciężkie argumenty wytaczane przez użytkowników ibatis albo hibernate przeciwko takiemu kodowi i tym wstretnym przeciążeniom operatorów
A tu jeszcze ciekawy post jakby ktoś sie już pogubił w tych nowych bebechach
Jak narazie jestem zachwycony jak uporządkowano AR. Wiem ze teraz jest boom na NoSQL etc ale jakoś nie przekonują mnie te wszystkie nowe technologie i jako tradycjonalista widze znowu duży potencjał AR 3.0 za rogiem
Popularność NoSQL nie bierze się z tego, że SQL jako język jest zły czy model relacyjny obsysa – wprost przeciwnie.
Popularność NoSQL bierze się z mocnej denormalizacji, co bardzo dobrze wpływa na wydajność i ułatwia (a przynajmniej umożliwia) sharding.
[quote=Tomash]Popularność NoSQL nie bierze się z tego, że SQL jako język jest zły czy model relacyjny obsysa – wprost przeciwnie.
Popularność NoSQL bierze się z mocnej denormalizacji, co bardzo dobrze wpływa na wydajność i ułatwia (a przynajmniej umożliwia) sharding.[/quote]
Mam tego świadomośc, nie chcem wywoływać zadnego flejma, chociaż już pewnie to zrobiłem Wiem tylko że w 99 % przypadkach w (moim) życiu codziennym denormalizacja do strzał w stope. I o ile w początkowych fazach projektów użycie NoSQL wydaje się proste (brak schematu bazy), szybkie (nie trzeba tworzyć migracji), przyjemne (Dane jako Dokument) o tyle w momencie gdy ktoś chce zacząć agregować te wszystkie dane robi sie nieprzyjemnie. Rozwiązaniem może być hurtownia danych, jakiś zewnętrzny system BI etc. ale czasem klient chce mieć to wszystko odrazu, w aplikacji ;[
[quote=Paweł Kondzior][quote=Tomash]Popularność NoSQL nie bierze się z tego, że SQL jako język jest zły czy model relacyjny obsysa – wprost przeciwnie.
Popularność NoSQL bierze się z mocnej denormalizacji, co bardzo dobrze wpływa na wydajność i ułatwia (a przynajmniej umożliwia) sharding.[/quote]
Mam tego świadomośc, nie chcem wywoływać zadnego flejma, chociaż już pewnie to zrobiłem Wiem tylko że w 99 % przypadkach w (moim) życiu codziennym denormalizacja do strzał w stope. I o ile w początkowych fazach projektów użycie NoSQL wydaje się proste (brak schematu bazy), szybkie (nie trzeba tworzyć migracji), przyjemne (Dane jako Dokument) o tyle w momencie gdy ktoś chce zacząć agregować te wszystkie dane robi sie nieprzyjemnie. Rozwiązaniem może być hurtownia danych, jakiś zewnętrzny system BI etc. ale czasem klient chce mieć to wszystko odrazu, w aplikacji ;[[/quote]
Dlatego trzeba wybierać mądrze. My użyliśmy MongoDB między innymi w projekcie gdzie było bardzo dużo danych katalogów, produkty z różnym zestawem danych, w różnych kategoriach itd. Mało relacji pomiędzy rekordami. Do takich celów bazy NoSQL nadają się idealnie.
A zapeniam że do aplikacji typu CMS, blogi, twittery, blipy i fejsbuki również.
Raczej nie nadają się do aplikacji w stylu “pomocnik księgowej” itd.
[quote=Tomash]Popularność NoSQL nie bierze się z tego, że SQL jako język jest zły czy model relacyjny obsysa – wprost przeciwnie.
Popularność NoSQL bierze się z mocnej denormalizacji, co bardzo dobrze wpływa na wydajność i ułatwia (a przynajmniej umożliwia) sharding.[/quote]
Mnie szczerze mówiąc mało obchodzi wydajność. Najlepsze jest to, o czym napisał Hubert - brak schematu umożliwia właściwie nieograniczone wersje każdego rekordu.
Nazwij jedną, która przy zachowaniu relacyjnego modelu się dobrze sharduje. I dare you, I double dare you
A co do artykułu: te cztery “overhead components” są spokojnie do znalezienia we współczesnych document-store’ach, natomiast dane schema-less za pomocą serializacji to można było mieć w relacyjnych bazach ZAWSZE.
Mogę Ci nawet podpowiedzieć, żebyś szukał w okolicach jednego z ostatnich ficzerów (to chyba nawet w formie dodatku było, a nie części core produktu) Oracle
Jeszcze tak a propos shardingu bo dyskuujecie tak jakby był to ficzer bez którego nie da się żyć. Nawet w bazach nosql, sharding wymusza pewne ograniczenia, upośledza bazę w stopniu często nie akceptowalnym. W aplikacjach które mają przechowywać na prawdę spore ilości danych może być przydatny ale zwykle nikogo nie obchodzi.
Co?[/quote]
Bo tak jest. Argumenty które przytaczasz nie są prawdziwe, a zapał godzien rewolucjonisty ;). Sharding dla większości ludzi używających np. MongoDB nie istnieje. Za to brak ściśle określonej struktury danych - a i owszem. Twierdzisz że można to było w bazach SQLowych osiągnąć “ZAWSZE”. Zgadzam się, tylko pytanie jakim kosztem? col1, col2, col3, … col666 ? Każde pole jako powiązany rekord z innej tabeli? Zapisywać zserializowane dane, chociażby do XMLa przy pomocy postgresa? Jasne że da się. Ale będzie to a) trudne b) wolne c) zagmatwane. Bazy danych NoSQL rozwiązują ten właśnie problem elegancko, i ich popularność bierze się właśnie z tej milutkiej cechy.
ale jakoś nie przekonują mnie te wszystkie nowe technologie i jako tradycjonalista widze znowu duży potencjał AR 3.0 za rogiem 
