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

[metaclass]

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

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

Comments

[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 используется как просто mapping. Если же именно изменения в схеме, то тут вас можно понимать по разному, может я не правильно вас понял, но компиляции изменения в модели побоку, потому как на этапе компиляции никакого подключения к БД не происходит, или вы что то ещё имели в виду?

Кстати где именно должны вылезать ошибки, на этапе компиляции или на этапе тестирования - это кому как нравится, можно легко на этой почве разжешь холивор dynamic vs static typing :)

[w00dy.livejournal.com]

Я в том смысле как это видится в том же nhibernate. Т.е. схема она в базе, маппинги в коде. Меняем схему, меняем маппинг и компилятор показывает что где сломалось. Если же в коде наличествует sql в больших кол-вах, то получается ад и израиль, ибо нужно теперь и его каким-то образом ослеживать. Конечно от этого спасают хранимки, но результат их работы тоже куда-то нужно мапить (тем же ормом?)

PS кончено же static typing рулит и бибикает :)

[dr-hyder.livejournal.com]

Всё то же самое происходит ежели использовать hibernate и писать на hql :) Если писать SQL то такая проблема есть конечно, надо осторожно, плюс тесты должны быть. Если же его не используют а пишут на всяких питонах, то там точно тесты должны быть :)

[w00dy.livejournal.com]

hql, если я правильно понимаю, это некий аналог linq из .net?

[dr-hyder.livejournal.com]

Нет, не совсем, это такой SQL для хайбернейт, тобишь оперирует он не напрямую над БД, а над уже замаплеными сущностями хайбернейта, есть ещё jpql (http://en.wikipedia.org/wiki/Java_Persistence_Query_Language), то же самое фактически, для JPA.

[tzirechnoy.livejournal.com]

От этого спасают юнит-тэсты.

Не, то есть есть варианты там embedded SQL или навесок к lintам всяким, но я предпочитаю полагаться на юнит-тэсты.

[w00dy.livejournal.com]

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

[tzirechnoy.livejournal.com]

Хм. Если что-то одновременно не нашли при рефакторинге и не покрыли юнит-тэстами -- то оно вылезет при боевом тэстировании. Но... У меня обычно всё находится ри рефакторинге. И я знаю что надо делать, если юнит-тэсты покрывают недостаточно функцыональности.
А вот что будут делать любители не-хаскелль компилятора когда он молча проглотит бывшый правильным тайпкастинг -- вот это мне интересно.

[http://users.livejournal.com/_windwalker_/]

юнит тесты не могут спасать от разницы между базой данных и маппингом.

это может быть оформлено как unit-test, но будет являться чем-то большим.

[tzirechnoy.livejournal.com]

>юнит тесты не могут спасать от разницы между базой данных и маппингом.

Хм?

>это может быть оформлено как unit-test, но будет
> являться чем-то большим.

Ну, хоть горшком, в принцыпе.
Скажыте, а файлы читать/писать юнит-тэстам тожэ нельзя?

[henu3detb.livejournal.com]

Чаво? Какой ОРМ ругается на этапе компиляции?

[w00dy.livejournal.com]

мапинг в орме то руцями пишется (или чем-то генерируется). Не?

[henu3detb.livejournal.com]

Чем пишется?
Компилятор может только откомпилировать. Проверить что схема и маппинги совпадают можно в лучшем случае при старте, если фреймворк это сделает. Как правило о проблемах маппинга узнают в рантайме.
На самом деле, если брать хибернейт в частности, то некорректный маппинг это одна сотая часть проблем с ним. Остальные проблемы с которыми сталкиваешься можно найти на форуме. Вот статистика оттуда: Topics: 61805, Posts: 190164.

[dr-hyder.livejournal.com]

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

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

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

[dr-hyder.livejournal.com]

Ну привет с другой стороны Ла-манша :)

[tzirechnoy.livejournal.com]

+1