Обучение частным случаям частных реализаций

[metaclass]

http://d4s.livejournal.com/210142.html
Вопрос про обучение SQL. Не про продажу человеко-часов конкретному кастомеру с конкретной СУБД.
В комментариях ад содома и гоморры, с приведением каких-то дичайших конструкций из частных реализаций.

Людей нужно хотя бы обучить тому, что такое реляционная модель, что такое индексы и как вообще связаны эти буковки с результатом. А уж конкретные извращения можно изучить в процессе работы с конкретной БД, очевидно, что засирать этим голову ДО понимания базовых вещей совершенно не нужно.

Comments

[w00dy.livejournal.com]

Ребе, а кому-то эти базы с sql сейчас вообще нужны? Современная мода (да и всякие народные фреймворки) юзают ормы. Голый доступ к базе остался где-то в коровавом энтерпрайзе, кмк. Иль я не прав?

PS мну уже давно пользует только orm. Ну а голый sql остаётся в паре мест и то сугубо для целей оптимизации производительности где это критично.

[dr-hyder.livejournal.com]

> Голый доступ к базе остался где-то в коровавом энтерпрайзе, кмк. Иль я не прав?

Не понял, в энтерпрайзе как раз сплошной ORM, далеко не все пишут стотыщ stored procedures. Противников же ORM примерно столько сколько и сторонников. Но по эмпирическим наблюдениям, если компания индусская то пользуются ORM, если не индусская то ORM пользуются для простых CRUD, всё остальное ручками.

[w00dy.livejournal.com]

а смысл делать "остальное ручками"?

[dr-hyder.livejournal.com]

А смысл делать остальное на ORM? Оно нужно для type-safe mapping и всё, запросы пишутся либо на SQL, либо на каком нибудь HQL, если это hybernate.

[w00dy.livejournal.com]

> А смысл делать остальное на ORM?

Для того чтобы любые изменения в схеме вылезали на этапе компиляции, а не тестирования. Не?

[dr-hyder.livejournal.com]

Это как раз индусы, судя по всему. У НЕ-индусов как правило есть один-два умнейших человека которые без всякой демократии насаждают своё жёсткое вИдение, а остальные индусы :)

>слой объектной абстракции доступа к реляционной СУБД (ORM/ОРП) в большинстве случаев скрывает не базу данных от приложения, а некомпетентность авторов приложения в области баз данных. Скрывает, разумеется, до поры до времени.

Это надо высекать на камне и ебошить этим камнем любителей ORM, пока SQL не выучат. Проще говоря - это общеизвестно.

[tzirechnoy.livejournal.com]

+1

[dair-spb.livejournal.com]

О, мил человек, а расскажите мне, который кроме SQL ничего не знает — как на орме (абстрактном в вакууме) написать более-менее сложный селект? Ну там с вложенностью, аутер джойнами...

Вот пример из моего приложения, холст, масло C#, PostgreSQL:
SELECT Q.CYCLE_ID AS ID, C.KEY AS TICKER, C.NAME AS NAME, Q.PRICE AS QUOTE, Q.TRADE_LIMIT AS TRADE_LIMIT, Q.NPCS_BUY AS NPCS_BUY FROM STOCK_COMPANY C LEFT OUTER JOIN STOCK_QUOTE Q ON (C.KEY = Q.COMPANY_KEY AND Q.CYCLE_ID IN (SELECT MAX(ID) FROM STOCK_CYCLE))

[dr-hyder.livejournal.com]

Да примерно так же (http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html#queryhql-select). Нормальные люди пользуются ORM по назначению, как object-relational mapping, плюс как бонус простейшие запросы можно не писать а функции вызывать, я понимаю что там можно огород городить и извращаться, но если по хорошему SQL всё равно нужно знать.

[w00dy.livejournal.com]

да фиг его знает. орм требует другого подхода к снаряду, и просто так взять и переписать sql это не правильный вариант. Основное удобство orm в том что он даёт строгую типизацию при работе с базой. Меняется схема, правятся классы и дальше уже компилятор покажет где чего поламалось в коде.

[tzirechnoy.livejournal.com]

А, то есть Вы тожэ подтверждаете, что работать в рамках реляцыонной модэли через ORM невозможно. Ну да, ну да.

Внимание, вопрос: а нафига нужна реляцыонная база данных, если не работать с реляцыонной модэлью данных?

[dr-hyder.livejournal.com]

Ну вообще говоря реляционные базы данных очень часто используют просто как storage, все эти реляции им нафиг не упали, только мешают. Посмотрите на всё(ну хорошо, не на всё, но значительную часть) nosql движение, например. Люди наконец осознали что в принципе для их потребностей городить огороды не обязательно, достаточно документа со плавающей схемой на энтити, как в каком нибудь MongoDB и всё, реляционность, транзакции и прочие триггеры там не нужны. И ничо, работает, нормально.

Пытаться же из ORM выжать функциональность SQL, только в "удобном, обьектном" виде - это лучше себе сразу ногу прострелить, не мучица.

[w00dy.livejournal.com]

Всё можно, если осторожно. Конкретно по запросу - нет контекста в котором он используется. А без контекста делать что-то безсмысленно.

А база нужна потому что на неё объектная модель красиво ложится. Между объектами ведь тоже есть отношения всякого рода и их нужно хранить и уметь выбирать.

[avnik.livejournal.com]

Ну вот как то так наверное:
http://docs.sqlalchemy.org/en/latest/orm/tutorial.html#querying-with-joins

[(Anonymous)]

Вы не поверите. Я тут попал в МТС и ребята на слово ОРМ спрашивают что это такое. Кстати ребята сами по себе неплохие.

select(from=stock_company).left_join(key=company_key).in(top.max(id),where=stock_cycle)

[tzirechnoy.livejournal.com]

А что, кто-то кроме конченных быдлокодеров ещё пишэт на ORM? Мне казалось, что ещё пятилетку назад вменяемые люди поняли, что это безсмыслица -- пытаться выразить реляцыонные понятия в объектных диалектах.

[w00dy.livejournal.com]

Очередной песец элементарных селектов?

[theiced.livejournal.com]

реляционные понятия не нужны в 99.99999% случаев. те пидорюги который городят неныжный сикль там где он соответсвенно не нужен (а не нужен он - см. выше %) должны сдохнуть от диареи сожрав собственное говно.

[metaclass.livejournal.com]

Я не знаю, как белорусскую налоговую отчетность делать на мап-редьюс и eventual consistency.
Вернее знаю, но это какой-то закат солнца вручную, откровенный.

[theiced.livejournal.com]

логика не должна быть в базе. база - тупой сторэж который может сделать select * from foo where bar=baz и ничего более.

[tzirechnoy.livejournal.com]

Как раз реляцыонные понятия нужны в 95% случаев. Но иногда они обходятся слишком накладно по ресурсам, хотя и присутствует в абстрагировании предметной области (скидываем ещё 5%). Вот в этих 10% нужно обходится без реляцыонных понятий при программировании. Те пидоргюги, который городят корявый ORM там где он соответственно вреден -- должны сдохнуть и пр.

В остальных 5%, кстати -- мне, на самом деле, жаль что у нас так плохо с графовыми, деревянными, и в особенности с Hindley-Miller-типизированными ACID-базами. SQLю было бы значительно лучшэ, если бы те, кому нужно именно это, не занимались бы закатом солнца вручную.

[(Anonymous)]

Вы не поверите. Я тут попал в МТС и ребята на слово ОРМ спрашивают что это такое. Кстати ребята сами по себе неплохие.

[norguhtar.livejournal.com]

Основная проблема с ORM это увеличение возможности просчета на стадии проектирования. Проще говоря все равно надо СНАЧАЛА спроектировать базу данных, а уже потом натягивать туда ORM. Иначе можно существенно потом получить проблемы с производительностью которые будут исправляться сложно долго и нудно. Ну и плюс аналитику делать на ORM несколько кхм.