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

[metaclass]

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

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

Comments

[si14.livejournal.com]

Ну, на самом деле, есть смысл в кауче/риаке. Причём первый можно, при желании, навелосипедить на втором. CRDT же. К Mongo сотоварищи это, конечно, не относится.

[metaclass.livejournal.com]

Какое редко? Ребе, у меня 99% опердени состоит из таких и более сложных запросов.

Другое дело, что логику оттуда надо действительно нахер выкинуть, но конкретно where/index by/group by надо выполнять в БД. А поскольку там все занормализовано - в эти выражения попадают поля из связанных таблиц и в итоге я в душе не ебу, как это написать на ORM так чтобы он сгенерировал нужный SQL запрос.

[w00dy.livejournal.com]

Ну в чём пробелмы то. where генерится чрезе Where (), всякие group by - при выборке подчинёных объектов. Как генерить запросы - но вы ведь чем-то думали когда писали sql, вот аналогично и при написании кода, только у вас не таблица A и B, а объекты А и B и связи между ними. Всё просто.

[norguhtar.livejournal.com]

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

[nivanych.livejournal.com]

Как реляционная алгебра!

[metaclass.livejournal.com]

И работает только для MSSQL провайдера, только на с# и только в одной версии дотнета, да.

[w00dy.livejournal.com]

Ну почему? Linq вроде как nHibernate поддерживает, есть провайдеры у DevExpress под кучу баз. Разботает на всём .net-овском есть. Запросы ведь не обязательно писать в этом sql-ном стиле. Можно и T ().Where (u => u.Id == userId).Select (u => u.Name).First ()

[dr-hyder.livejournal.com]

Ну вообще говоря отсутствие схемы это фича, во многих местах очень полезная, практически незаменимая. Если вы хотите наоборот контроля за схемой(что ясное дело тоже обычный юзкейс) тогда она вам не очень подходит. Но есть ещё возможность не давать прямой доступ к схеме, а давать доступ только через сервис. Для RDBMS это менее полезно потому как там люди часто хотят делать всякие ad-hoc запросы, аггрегировать и вообще RDBMS людей несколько развратили подобными возможностями, до того что сложно представить как можно жить без них. Для монго это нормальная практика, дающая множество преимуществ(хотя конечно далеко не везде применимая). Но монго это не замена RDBMS, она для других целей. Если вам не подходит - неча на монго пенять.

[tzirechnoy.livejournal.com]

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

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

[tzirechnoy.livejournal.com]

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

[tzirechnoy.livejournal.com]

Да правильно, в общем, знают на самом деле. Зачем оптимизировать нетормозящее? Действительно, количество подразделений очень ограниченно тысячью максимум тридцатью (да и то это, скорее масштба спец.службы сверхдержавы). В общем, не с той стороны Вы их по-моему пинаете.

[falcrum.livejournal.com]

Если не надо, чтоб работало - может и заменить.

[metaclass.livejournal.com]

А потом приходят внедренцы и натягивают сову на глобус, ставя приложение в какую-нибудь налоговую службу и заводя каждого человека отдельным подразделением :)

[tzirechnoy.livejournal.com]

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

[blackyblack.livejournal.com]

Логика не должна быть в базе, но как тупой сторэдж тоже не получится.

[tzirechnoy.livejournal.com]

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

Хм?

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

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

[tzirechnoy.livejournal.com]

Я совершэнно не спорю, что во многих технологиях, которые называют "nosql", есть смысл. Я говорю, что нет смысла в слове "nosql".

[blackyblack.livejournal.com]

В коментах по ссылке всё правильно пишут. Хрена ли тот SQL изучать, когда на конкретной СУБД всё сломается. Да даже те же primary keys не заведёшь без гугла. Адекватные специалисты давно поняли, как реляционная алгебра работает, а весь остальной их опыт - тупо набивание шишек на самых разных реализациях.
Да, если автору нужно было тупо учить студентов, то можно дать им книжку прочитать и не парить мозг.

[si14.livejournal.com]

Угу, соглашусь.

[vit-r.livejournal.com]

Дискуссия по ссылке напомнила одну лекцию. Как-то давно люди из Оракла показывали офигеннейшей сложности тул, оптимизирующий запросы. Реальный такой тул с пятизначной ценой за рабочее место. После всех глубин и высот в сухом остатке было предложение полученные оптимизированные запросы тестировать на реальных данных. Потому как только измерения и только на реальных объёмах могут показать, как на самом деле оно внутри будет выполняться.

[dair-spb.livejournal.com]

Я тут тебя, Андрей, наслушался, взял в руки рельсы.

Три дня (вечорами) пытался структуру БД изложить в модельках — хер там был.
Селект из двух таблиц со связкой в один запрос - тоже хер, хотя казалось бы. includes() генерит второй селект, where которого выглядит как id in (1,2,3,4,5,6,7,8.....)
Я преставил, что будет, если канал до БД не резиновый.

Но (но) веб на рельсах пишу, ничо так. Но БД — ну нахер, буду руками селекты писать.