Господа, по ходу развития темы у меня появились следующие мысли.

Одним из недостатоков linq является затрата времени на разбор expression tree в рантайме. Строится AST, склеивается sql-строка, посылается в СУБД, там опять разбор этой строки, дерево...
Между тем sql — это высокоуровневый API доступа к БД. Но бывает и низкоуровневый.
Почему бы не выкинуть промежуточные этапы? После построения AST на клиенте передавать прямо его в СУБД. В итоге затраты времени linq уменьшат затраты времени в СУБД.
Можно возразить, что это несовместимо с легаси системами. Да и пофиг! NoSQL-решения тоже несовместимы с РСУБД, однако быстро завоевали популярность.

Далее. Апологеты линка напирают на то, что при его грамотном применении не нужны хранимые процедуры. С чем я в целом согласен.
Большинство СУБД постепенно обрастают новыми возможностями, начитают сочетать в себе SQL и NoSQL, между тем они нужны далеко не всем.
Вот здесь, например, упомянута версия MySQL, из которой убраны многие фичи: хранимки, триггеры и др. В результате она стала работать в три раза быстрее.
Хотелось бы иметь такую СУБД, которую можно собирать как из кубиков (модулей): нужны хранимки — подключаем модуль, нужны триггеры — подключаем, не нужны — не подключаем. То есть, если мы планируем использовать linq для доступа к БД, то можно полностью убрать модуль разбора sql-строк.
Выгода может быть и в том, что убрав ненужные фичи, можно снизить потребление памяти, в итоге больше страниц БД будет помещаться в ОЗУ. Это к спору о нужности/ненужности кэшированиия в самой СУБД.

Здравствуйте, koodeer, Вы писали:

K>Хотелось бы иметь такую СУБД, которую можно собирать как из кубиков (модулей): нужны хранимки — подключаем модуль, нужны триггеры — подключаем, не нужны — не подключаем. То есть, если мы планируем использовать linq для доступа к БД, то можно полностью убрать модуль разбора sql-строк.
K>Выгода может быть и в том, что убрав ненужные фичи, можно снизить потребление памяти, в итоге больше страниц БД будет помещаться в ОЗУ. Это к спору о нужности/ненужности кэшированиия в самой СУБД.

Большая часть существующих СУБД пишутся с конца 80х годов. Это одна из самых сложный вещей, какие только есть в IT. Что-то на уровне "давайте сделаем" тут не прокатит, делать придется очень-очень много.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС> У юзеров иногда метки рядом с ником бывают — expert, admin и т.д.

Так это же вроде прямые свойства пользователя. Почему в отдельной таблице?

НС>Нет, речь была про общий случай, который ты упорно пытаешься сузить.

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

НС>Вопрос непонятен.

ОК, уточню конкретнее. В в случае использования слоя абстракции у нас в прикладном коде будут следующие строки:

AddUser(name);
...
auto user=GetUser(id);

Так вот вопрос был простой — как будет выглядеть этот же код в случае отсутствия слоя абстракции и использование linq. Содержимое данных функций (т.е. слоя) я уже приводил в предыдущих сообщения.

_>>Угу, только в сайтах на "движках" почему-то вся функциональность всегда работает
НС>Агащаз.

Во всяком случае уведомления по почте у меня приходят от всех форумов, построенных на стандартных движках. В отличие от форума rsdn.

_>> (причём там есть к примеру форумы входящие в топ alexa, т.е. понятно с какими дикими нагрузками)
НС>А ты уверен что там нетроганный руками движок на этих диких нагрузках?

Во внутренности я конечно не лазил, но внешне совершенно обычный и со всей стандартной функциональностью.

НС>Ну вот и выхода у них другого нет, приходится лишний слой городить.

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

_>>Вроде как ты сам в соседней темке ругал Шеридана за то, что он писал свой велосипед, вместо использования готового решения.
НС>Вот уж передернул так передернул.

А что не так то? ) Т.е. написание своего велосипеда вместо использования готового движка системы управления задачами — это дикий непрофессионализм начальника IT отдела. Но при этом написание своего велосипеда вместо использования готового движка форума — это признак "приличного сайта". У тебя всё в порядке с логикой? )))

Здравствуйте, koodeer, Вы писали:

K>Одним из недостатоков linq является затрата времени на разбор expression tree в рантайме. Строится AST, склеивается sql-строка, посылается в СУБД, там опять разбор этой строки, дерево...
K>Между тем sql — это высокоуровневый API доступа к БД. Но бывает и низкоуровневый.
K>Почему бы не выкинуть промежуточные этапы? После построения AST на клиенте передавать прямо его в СУБД. В итоге затраты времени linq уменьшат затраты времени в СУБД.

Интересная идея. Но для этого авторы ведущих СУБД должны договориться о едином стандарте AST, что практически невероятно. Они и с вроде как уже стандартизованным SQL умудряются плодить несовместимости. А тут нет даже намёка на стандарт.

K>Вот здесь, например, упомянута версия MySQL, из которой убраны многие фичи: хранимки, триггеры и др. В результате она стала работать в три раза быстрее.

Интересная статья.

K>Хотелось бы иметь такую СУБД, которую можно собирать как из кубиков (модулей): нужны хранимки — подключаем модуль, нужны триггеры — подключаем, не нужны — не подключаем. То есть, если мы планируем использовать linq для доступа к БД, то можно полностью убрать модуль разбора sql-строк.

Пока что дело идёт как раз к противоположному — в одной базе будут вообще все вообразимые возможности (и slq и nosql и т.д.). ))) Другое дело, будет ли вносить их факт существования какие-то накладные расходы (речь про неиспользуемые).

Здравствуйте, alex_public, Вы писали:

НС>> У юзеров иногда метки рядом с ником бывают — expert, admin и т.д.
_>Так это же вроде прямые свойства пользователя. Почему в отдельной таблице?

Интересные ты вопросы задаешь. Связь много к одному насколько я понимаю.

НС>>Нет, речь была про общий случай, который ты упорно пытаешься сузить.
_>В том то и дело, что тот подход, о котором я говорю, и рассматривает только конкретные узкие случаи.

Ну так давай рассмотрим неудобные случаи тогда. Когда выборка не по кластерномуиндексу и поля не все нужны.

НС>>Вопрос непонятен.

_>ОК, уточню конкретнее. В в случае использования слоя абстракции у нас в прикладном коде будут следующие строки:
_>

_>AddUser(name);
_>...
_>auto user=GetUser(id);
_>

_>Так вот вопрос был простой — как будет выглядеть этот же код в случае отсутствия слоя абстракции и использование linq.

AddUser(...);
var user = db.Users.Find(id);

_>>> (причём там есть к примеру форумы входящие в топ alexa, т.е. понятно с какими дикими нагрузками)
НС>>А ты уверен что там нетроганный руками движок на этих диких нагрузках?
_>Во внутренности я конечно не лазил, но внешне совершенно обычный и со всей стандартной функциональностью.



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

А тебе пишут, что такое прокатывает только на очень примитивных сценариях работы с БД. Но ты не слышишь.

_>>>Вроде как ты сам в соседней темке ругал Шеридана за то, что он писал свой велосипед, вместо использования готового решения.
НС>>Вот уж передернул так передернул.
_>А что не так то?

Я даже объяснять не буду.

Здравствуйте, alex_public, Вы писали:

_>Интересная идея. Но для этого авторы ведущих СУБД должны договориться о едином стандарте AST, что практически невероятно. Они и с вроде как уже стандартизованным SQL умудряются плодить несовместимости. А тут нет даже намёка на стандарт.

Я согласен, что единый стандарт — это нечто нереальное. Однако, он и не нужен. В любом случае для доступа к БД используются свои linq-провайдеры. Соответственно, если, например, MS реализует в своём сервере такую фичу, то и провайдер специальный предоставит. А провайдеры других БД будут по-прежнему отсылать готовую sql-строку.


_>Пока что дело идёт как раз к противоположному — в одной базе будут вообще все вообразимые возможности (и slq и nosql и т.д.). ))) Другое дело, будет ли вносить их факт существования какие-то накладные расходы (речь про неиспользуемые).

С этим тоже согласен. Однако, наряду с мощными навороченными СУБД широко используются и такие, как sqlite. Поэтому я бы не исключал возможность появления СУБД с урезанными возможностями в угоду повышения каких-либо других характеристик.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Типы проверяет не linq2db, а компилятор шарпа.
EP>>Ты о чём конкретно? Типы в C++ тоже проверяет компилятор

Автор: Evgeny.Panasyuk
Дата: 22.04.15

.
НС>

S>>Вопрос не в том, компилируемый он или нет. Вопрос в том, что помешает скомпилироваться и коду с ошибками.
НС>Помешает логика закодированная в коде который обходит дерево выражения.

НС>

Всё же о чём ты? О том что проверку на group by можно реализовать без явного обхода дерева выражений, через требование предварительного group by для агрегирования по типу как в LINQ? Да, это тоже реализуется в C++ — система типов ведь мощнее.
Я же показал общий принцип построения EDSL через деревья выражений, чтобы дать представление о всей широте возможностей

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Нет, не используется. Используется генерация кода.
EP>>Во время сборки/компиляции или в runtime? (bytecode emit?)
НС>Тулой во время сборки, без тулы при первом использовании в рантайме.

А где это всё в репозитории? Какие ключевые слова для поиска?

Здравствуйте, koodeer, Вы писали:

K>Здравствуйте, alex_public, Вы писали:

_>>Интересная идея. Но для этого авторы ведущих СУБД должны договориться о едином стандарте AST, что практически невероятно. Они и с вроде как уже стандартизованным SQL умудряются плодить несовместимости. А тут нет даже намёка на стандарт.

K>Я согласен, что единый стандарт — это нечто нереальное. Однако, он и не нужен. В любом случае для доступа к БД используются свои linq-провайдеры. Соответственно, если, например, MS реализует в своём сервере такую фичу, то и провайдер специальный предоставит. А провайдеры других БД будут по-прежнему отсылать готовую sql-строку.

Генерация и разбор строк занимают сотые или даже тысячные доли процентов от времени выполнения запроса.
На стороне СУБД дольше всего выполняется построение плана запроса. Но план строится один раз для одной входящей строки. Если повторно отправляем ту же строку, то она даже не парсится, а просто по хешу находится план в кеше планов.
На стороне приложения EF тоже имеет кеш запроса, то есть один раз быстро пробегает по дереву и ищет готовую строку SQL строку в кеше, не обрабатывая каждый раз мапинги, метаданные и генерацию мапперов.

Самое долгое во всем этом процессе — построение Expression на стороне .NET. Для экспрешенов испольуется рефлексия и строится они в рантайме.


_>>Пока что дело идёт как раз к противоположному — в одной базе будут вообще все вообразимые возможности (и slq и nosql и т.д.). ))) Другое дело, будет ли вносить их факт существования какие-то накладные расходы (речь про неиспользуемые).

K>С этим тоже согласен. Однако, наряду с мощными навороченными СУБД широко используются и такие, как sqlite. Поэтому я бы не исключал возможность появления СУБД с урезанными возможностями в угоду повышения каких-либо других характеристик.
Урезание возможностей == урезание гарантий, а урезание гарантий == больше телодвижений со стороны приложения чтобы все работало, в итоге это приводит к более медленной работе в среднем. Странно что многие этого не понимают. Урезание возможностей только в отдельных примитивных случаях может дать сколько-нибудь заметный прирост. А в остальных случаях все равно кеширование решает.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>И что? От того что ты сузил область обсуждения проблемы не исчезли. Это демагогический прием — "давайте рассмотрим маленький частный случай в котором выполняется условие Х, а потом неявно будем считать, что условие Х выполняется везде". К несчастью для тебя такой переход еще нужно обосновать. То что ты получая пользователя по id можешь вытягивать все поля примерно с той же скоростью, что и часть полей не говорит о том, что можно не писать проекции во всех остальных случаях.

_>1. Я не сузил — именно в такой постановке вопрос был изначально.
Значит ты изначально сузил до бесполезности.

_>2. Я как раз везде и говорю, что только делая разный код в каждой задаче (а не обобщённую ORM), можно добиться максимальной эффективности. Т.е. я как раз не предлагаю делать везде по образцу этого примера, а предлагаю искать оптимальное решение в каждом частном случае — это совсем не сложно.
Искать вообще несложно. Поддерживать очень сложно. База эволюционирует вместе с приложением, поэтому нужно не нарушать согласованность кода (запросов) и схемы, а если у тебя нет единого подхода, то это физически невозможно.

_>>>Т.е. это приложение должно подстраиваться под хранилище, а не наоборот? ) Забавно... )))
G>>В 99% случаев модель данных и приложение делает одна команда, поэтом неясно почему вообще кто-то должен подстраиваться.
_>Причём тут команда? ) В случае использования в приложение классов, являющихся отображением slq таблиц, у тебя модель данных ограничена реляционной моделью. )
И что? Это плохо? Реляционная модель мощнее, чем любая другая, используемая массово сегодня.

G>>То есть таки надо делать проекции. И мы прекрасно понимаем что в реальности на каждую таблицу будет более одной проекции. Внимание вопрос, как это поддерживать? Что будет если в таблице появляются новые поля, новые предикаты итп? Каждый раз править десятки функций?
_>Как раз при такой архитектуре и удобнее поддерживать в случае изменения БД, потому как все правки будут локальные (весьма возможно вообще в одном файле), а не раскиданы по всему коду приложения.
А ты с чем сравниваешь? С помощью linq площадь изменений всегда можно ограничить одной функцией за счет возможности декомпозиции запросов. Если у тебя 100500 отдельных функций, каждая из которых внутри делает свой запрос, то тебе понадобится править эти 1005500 функций, даже если они в одном файле. А на практике не в одном, потому что куча запросов с джоинами и одна и та же таблица может фигурировать в куче запросов разных сущностей.

_>>>Не надо им знать sql вообще, если есть нормальный слой абстракции. Ну или мощная ORM в крайнем случае.
G>>Практика показывает что надо. Без понимания SQL и механизмов работы СУБД программисты делают хреновые запросы, никакие инструменты не помогают.

_>Какие запросы? ) Все запросы сидят в слое абстракции, а наружу только функции без всяких опций.
А кто пишет функции? Они святым духом появляются?

_>Так что при описанной архитектуре как раз можно иметь в команде только одного специалиста по БД.
Сразу видно, что ни одного приложения такого уровня ты не написал. Я тебе уже писал что под каждый сценарий свой запрос нужен. Ты этого не понимаешь, потому что не делал такие приложения ни разу, так что прими это как данность.
Так вот когда происходят изменения, то нужно как минимум два человека — один поправит контроллеры и UI, а второй поправит запросы. И этот один специалист по БД становится узким местом процесса.
Но это только полбеды. Так как у такого специалиста много работы, то он начинает халявить и делает запросы общего вида, а потом из них вырезает нужный набор данных уже на стороне приложения. Это приводит к огромным тормозам в программе.

_>Более того, есть гарантии, что какой-нибудь криворукий новичок не накосячит со своими оригинальным запросом. )))
Появляется гарантия перманентного косяка с запросами.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Интересные ты вопросы задаешь. Связь много к одному насколько я понимаю.

Непонятно. В чём отличие метки от прав?

НС>Ну так давай рассмотрим неудобные случаи тогда. Когда выборка не по кластерномуиндексу и поля не все нужны.

Давай рассмотрим. Конкретный пример то будет? )

_>>Так вот вопрос был простой — как будет выглядеть этот же код в случае отсутствия слоя абстракции и использование linq.
НС>

НС>AddUser(...);
НС>var user = db.Users.Find(id);
НС>

Ага... Т.е. функция AddUser опять же появилась? ) А к какому тогда модулю приложения она относится, если не к слою абстракции БД? )
А что за функция Find? Это что-то встроенное в linq2db?

НС>А тебе пишут, что такое прокатывает только на очень примитивных сценариях работы с БД. Но ты не слышишь.

Я тебя слышал, но осталось определиться с тем, что значит "примитивные сценарии". Потому как для практически всех (т.е. даже если там и одна БД, то это упрощённая mysql) веб-движков этого более чем хватает. Может тогда уж стоит именно это назвать нормой (всё же большинство), а не укладывающиеся сюда сложные сценарии — извращениями? )

НС>Я даже объяснять не буду.

Ну правильно, двойные стандарты очень сложно объяснять...

Здравствуйте, alex_public, Вы писали:

НС>>Интересные ты вопросы задаешь. Связь много к одному насколько я понимаю.
_>Непонятно. В чём отличие метки от прав?

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

НС>>Ну так давай рассмотрим неудобные случаи тогда. Когда выборка не по кластерномуиндексу и поля не все нужны.
_>Давай рассмотрим. Конкретный пример то будет? )

Поиск пользователя по его нику. Выбрать нужно, скажем, его полное имя и права доступа. Есть индекс по нику, в который включены полное имя и права доступа.

_>Ага... Т.е. функция AddUser опять же появилась?

Я где то утверждал обратное?

_> ) А к какому тогда модулю приложения она относится, если не к слою абстракции БД? )

Ни к какому. Это может быть просто приватный метод в контроллере, если вызывается только там.

_>А что за функция Find? Это что-то встроенное в linq2db?

Генератор такие функции на все уникальные индексы создает.

_>Потому как для практически всех (т.е. даже если там и одна БД, то это упрощённая mysql) веб-движков этого более чем хватает.

Вот именно что твои примитивные веб-движки обходятся минимумом запосов. Только это не единственнон и даже не основное применение РСУБД.

_> Может тогда уж стоит именно это назвать нормой (всё же большинство), а не укладывающиеся сюда сложные сценарии — извращениями? )

Решил продолжить упражнения в демагогии?

НС>>Я даже объяснять не буду.
_>Ну правильно, двойные стандарты очень сложно объяснять...

Нет, не хочу заниматься демагогией. Интересно по делу пообщаться — велкам. Нет — давай, до свидания.

Здравствуйте, gandjustas, Вы писали:

_>>Причём тут команда? ) В случае использования в приложение классов, являющихся отображением slq таблиц, у тебя модель данных ограничена реляционной моделью. )
G>И что? Это плохо? Реляционная модель мощнее, чем любая другая, используемая массово сегодня.

Что значит мощнее? Приложение ограниченное реляционной моделью на уровне внутренних классов будет весьма убого выглядеть по сравнению с нормальным (где реляционная модель всплывает только при работе с хранилищем). Ну ты же сам хорошо понимаешь, что совершенно нормально иметь в приложение коллекции объектов, поля которых тоже являются коллекциями других объектов. Причём коллекции эти к тому же могут быть ещё не массивами, а скажем связными списками или вообще деревьями. Это всё абсолютно не соответствует реляционной модели, но при этом очень удобно в использование в приложение. А вот при реализации слоя абстракции БД, мы можем спокойно работать в приложение с такими сущностями и спокойно отправлять их в хранилище. А там уже слой абстракции разберётся как сохранить подобные объекты (например задействовать несколько таблиц со связями) в реляционной БД. А если очень захочется и в не реляционной.

G> А ты с чем сравниваешь? С помощью linq площадь изменений всегда можно ограничить одной функцией за счет возможности декомпозиции запросов. Если у тебя 100500 отдельных функций, каждая из которых внутри делает свой запрос, то тебе понадобится править эти 1005500 функций, даже если они в одном файле. А на практике не в одном, потому что куча запросов с джоинами и одна и та же таблица может фигурировать в куче запросов разных сущностей.

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

_>>Так что при описанной архитектуре как раз можно иметь в команде только одного специалиста по БД.
G>Сразу видно, что ни одного приложения такого уровня ты не написал. Я тебе уже писал что под каждый сценарий свой запрос нужен. Ты этого не понимаешь, потому что не делал такие приложения ни разу, так что прими это как данность.
G>Так вот когда происходят изменения, то нужно как минимум два человека — один поправит контроллеры и UI, а второй поправит запросы. И этот один специалист по БД становится узким местом процесса.
G>Но это только полбеды. Так как у такого специалиста много работы, то он начинает халявить и делает запросы общего вида, а потом из них вырезает нужный набор данных уже на стороне приложения. Это приводит к огромным тормозам в программе.

Откуда много работы? ) Взгляни на готовые реализации подобных слоёв абстракции. Они занимают совершенно незначительную часть (часто вообще один файл) от общего объёма кода приложения.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>IT, помнится, говорил что написать туда можно что угодно. Так что там явно две таблицы. Но мне нравится что ты споришь с задачей

Эмм, а почему в пользователя нельзя написать что угодно? И я пока ещё не спорю, а выясняю её детали.

НС>Поиск пользователя по его нику. Выбрать нужно, скажем, его полное имя и права доступа. Есть индекс по нику, в который включены полное имя и права доступа.

Странный индекс. ) Неужто завели специально для такого поиска? Он настолько востребован? ) Ну если действительно так, то можно под эти цели завести отдельную функцию с прямо такими параметрами. )

_>>Ага... Т.е. функция AddUser опять же появилась?
НС>Я где то утверждал обратное?

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

_>> ) А к какому тогда модулю приложения она относится, если не к слою абстракции БД? )
НС>Ни к какому. Это может быть просто приватный метод в контроллере, если вызывается только там.

Т.е. в данном случае по сути единственная разница твоего подхода со слоем абстракции БД является то, что ты оставляешь все подобные функции раскиданными по коду приложения, а не группируешь в одну область.

_>>А что за функция Find? Это что-то встроенное в linq2db?
НС>Генератор такие функции на все уникальные индексы создает.

Полезная штучка. И опять же не имеющая никакого отношения к sql. Т.е. по сути опять же часть слоя абстракции, только реализованная в библиотечке.

НС>Вот именно что твои примитивные веб-движки обходятся минимумом запосов. Только это не единственнон и даже не основное применение РСУБД.

А как мы определим основное применение? ) Например параметр числа инсталляции пойдёт или нет? )

НС>Нет, не хочу заниматься демагогией. Интересно по делу пообщаться — велкам. Нет — давай, до свидания.

Ну так вот у меня совершенно простой и полностью технический вопрос по делу: почему с твой точки зрения Trac (кстати умеет работать с 4-мя разными СУБД) — это хорошо, а phpBB — это плохо?

Здравствуйте, gandjustas, Вы писали:

G>Генерация и разбор строк занимают сотые или даже тысячные доли процентов от времени выполнения запроса.

Тем не менее к этим микросекундам были придирки. Поэтому я предложил способ избавления от них.


G>Урезание возможностей == урезание гарантий, а урезание гарантий == больше телодвижений со стороны приложения чтобы все работало, в итоге это приводит к более медленной работе в среднем. Странно что многие этого не понимают. Урезание возможностей только в отдельных примитивных случаях может дать сколько-нибудь заметный прирост. А в остальных случаях все равно кеширование решает.

Ещё раз скажу: очень многие разработчики БД считаю хранимки злом. Во всяком случае стараются их не использовать. Так вот если совсем выкинуть их из БД, какие гарантии ухудшатся?

А то что единый фреймворк .NET заменяется на набор отдельно подключаемых сборок ты как воспринмаешь? Если СУБД будет также свободно собираться из подключаемых сборок — в чём проблема?

Здравствуйте, alex_public, Вы писали:

НС>>IT, помнится, говорил что написать туда можно что угодно. Так что там явно две таблицы. Но мне нравится что ты споришь с задачей
_>Эмм, а почему в пользователя нельзя написать что угодно? И я пока ещё не спорю, а выясняю её детали.

Тогда императивно — там две таблицы и джойн между ними. Ибо достал уже искать способы не отвечать на вопрос.

НС>>Поиск пользователя по его нику. Выбрать нужно, скажем, его полное имя и права доступа. Есть индекс по нику, в который включены полное имя и права доступа.
_>Странный индекс. ) Неужто завели специально для такого поиска?

Да.

_> Он настолько востребован?

Да.

_> ) Ну если действительно так, то можно под эти цели завести отдельную функцию с прямо такими параметрами. )

Возвращать она чего будет?

_>>>Ага... Т.е. функция AddUser опять же появилась?
НС>>Я где то утверждал обратное?
_>Но по сути это и есть классическая абстракция от БД

Нет, это не абстракция от БД, это банальный extract method.

_>>> ) А к какому тогда модулю приложения она относится, если не к слою абстракции БД? )
НС>>Ни к какому. Это может быть просто приватный метод в контроллере, если вызывается только там.
_>Т.е. в данном случае по сути единственная разница твоего подхода со слоем абстракции БД является то, что ты оставляешь все подобные функции раскиданными по коду приложения, а не группируешь в одну область.

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

_>>>А что за функция Find? Это что-то встроенное в linq2db?
НС>>Генератор такие функции на все уникальные индексы создает.
_>Полезная штучка. И опять же не имеющая никакого отношения к sql.

И чо?

_> Т.е. по сути опять же часть слоя абстракции, только реализованная в библиотечке.

Нет, это не слой абстракции, эти функции прямо в классе БД расположены и от нее не астрагируются. Просто статические хелперы.

_>А как мы определим основное применение? )

С софистикой — к кому нибудь другому. Ты прекрасно понял о чем я. Но упорно пытаешься выдавать частности за целое.

_>Ну так вот у меня совершенно простой и полностью технический вопрос по делу: почему с твой точки зрения Trac (кстати умеет работать с 4-мя разными СУБД) — это хорошо, а phpBB — это плохо?

Потому что в phpBB приходится для каждой БД реализовывать и поддерживать весь код доступа к данным + лишний уровень абстракции.
Если у тебя этот слой примитивен это еще можно себе позволить, но если он чуть посложнее это превращается в бессмысленный перерасход времени и сил.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Тогда императивно — там две таблицы и джойн между ними. Ибо достал уже искать способы не отвечать на вопрос.

И это ты называешь конкретным случаем?

_>> ) Ну если действительно так, то можно под эти цели завести отдельную функцию с прямо такими параметрами. )
НС>Возвращать она чего будет?

Ну например bool. Что-нибудь вроде bool UserFullnameAndPermissions(const string name, string& fullname, string& permissions), раз уж идёт подобная оптимизация именно под такой странный поиск.

_>>Но по сути это и есть классическая абстракция от БД
НС>Нет, это не абстракция от БД, это банальный extract method.

Осталось только понять, для каких целей выполняют рефакторинг типа "выделение метода". )))

_>> Т.е. по сути опять же часть слоя абстракции, только реализованная в библиотечке.
НС>Нет, это не слой абстракции, эти функции прямо в классе БД расположены и от нее не астрагируются. Просто статические хелперы.

Естественно, это только часть абстракции, а не полный слой. На полный авторов linq2db не хватило. Но бывают и такие ORM (там обычно только функции вида db.persist(object) и т.п.). Правда на мой вкус это не совсем хорошая вещь (т.к. нельзя сделать подобное оптимально для произвольного случая), но многие с удовольствием пользуются.

_>>А как мы определим основное применение? )
НС>С софистикой — к кому нибудь другому. Ты прекрасно понял о чем я. Но упорно пытаешься выдавать частности за целое.

Аналогично могу сказать и про тебя. Если в твоём узком мирке процветают исключительно slq запросы в страницу кода, то не стоит мерить весь мир по себе. Возможно что как раз твой случай исключение из правил, а в нормальном мире совсем другие привычки.

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

_>>Ну так вот у меня совершенно простой и полностью технический вопрос по делу: почему с твой точки зрения Trac (кстати умеет работать с 4-мя разными СУБД) — это хорошо, а phpBB — это плохо?
НС>Потому что в phpBB приходится для каждой БД реализовывать и поддерживать весь код доступа к данным + лишний уровень абстракции.
НС>Если у тебя этот слой примитивен это еще можно себе позволить, но если он чуть посложнее это превращается в бессмысленный перерасход времени и сил.

Ну так у Trac'a же всё абсолютно точно так же, однако его ты рекомендовал.

Здравствуйте, alex_public, Вы писали:

НС>>Тогда императивно — там две таблицы и джойн между ними. Ибо достал уже искать способы не отвечать на вопрос.
_>И это ты называешь конкретным случаем?

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

_>>> ) Ну если действительно так, то можно под эти цели завести отдельную функцию с прямо такими параметрами. )
НС>>Возвращать она чего будет?
_>Ну например bool. Что-нибудь вроде bool UserFullnameAndPermissions(const string name, string& fullname, string& permissions)



_>>>Но по сути это и есть классическая абстракция от БД
НС>>Нет, это не абстракция от БД, это банальный extract method.
_>Осталось только понять, для каких целей выполняют рефакторинг типа "выделение метода". )))

http://en.wikipedia.org/wiki/Code_refactoring

Extract Method, to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions.

_>>> Т.е. по сути опять же часть слоя абстракции, только реализованная в библиотечке.
НС>>Нет, это не слой абстракции, эти функции прямо в классе БД расположены и от нее не астрагируются. Просто статические хелперы.
_>Естественно, это только часть абстракции

Это вообще не абстракция. Оно ничего не абстрагирует, просто сокращает код.

НС>>Потому что в phpBB приходится для каждой БД реализовывать и поддерживать весь код доступа к данным + лишний уровень абстракции.
НС>>Если у тебя этот слой примитивен это еще можно себе позволить, но если он чуть посложнее это превращается в бессмысленный перерасход времени и сил.
_>Ну так у Trac'a же всё абсолютно точно так же, однако его ты рекомендовал.

Нет, у Трака не так же. У него вообще очень тонкий слой изоляции от БД. Несколько БД поддерживает только базовый уровень, который у трака совсем простой. А запросы посложнее, которые нужны когда ты тикеты как то хитро выбрать хочешь, вот прям в SQL целевой БД и пишутся.
Если что, я несколько плагинов к Траку написал. так что примерно в курсе как оно устроено.
Более того, Postgre и SQLite имеют очень близкий синтаксис, а MySQL:

MySQL is supported by Trac since 0.10, but there are some caveats

Причем caveats порой прекрасны:

We have been dealing with extremenly poor Trac performance when using MySQL as the backend database.
...
We are running Trac with 10k tickets, and some modules need query through TracQuery a lot, but we found backend MySQL's load is heavy.
...
With NDB engine, TEXT(BLOB) column cannot be used as PRIMARY KEY. So such columns will be used as VARCHAR.
Maximum ROW size for NDB engine is 8052. So, long wiki, tickets and etc are cut off by limit.

И это ровно то, о чем тебе пытаются вдолбить несколько человек — пытаешься поддержать несколько БД без переписывания всех запросов — получаешь непотребный перфоманс.

Здравствуйте, koodeer, Вы писали:

G>>Урезание возможностей == урезание гарантий, а урезание гарантий == больше телодвижений со стороны приложения чтобы все работало, в итоге это приводит к более медленной работе в среднем. Странно что многие этого не понимают. Урезание возможностей только в отдельных примитивных случаях может дать сколько-нибудь заметный прирост. А в остальных случаях все равно кеширование решает.

K>Ещё раз скажу: очень многие разработчики БД считаю хранимки злом. Во всяком случае стараются их не использовать. Так вот если совсем выкинуть их из БД, какие гарантии ухудшатся?
Хранимки дают типобезпосность. Если ты не в курсе, то ad-hoc запросы с параметрами в MS SQL реализуются через хранимку. А в некоторых базах транзакционность возможна только в хранимках.

Кроме того есть такая штука как тригеры, которая по сути поверх хранимок работает.

K>А то что единый фреймворк .NET заменяется на набор отдельно подключаемых сборок ты как воспринмаешь? Если СУБД будет также свободно собираться из подключаемых сборок — в чём проблема?
Не понял вопроса.

Здравствуйте, alex_public, Вы писали:
_>Что значит мощнее? Приложение ограниченное реляционной моделью на уровне внутренних классов будет весьма убого выглядеть по сравнению с нормальным (где реляционная модель всплывает только при работе с хранилищем). Ну ты же сам хорошо понимаешь, что совершенно нормально иметь в приложение коллекции объектов, поля которых тоже являются коллекциями других объектов. Причём коллекции эти к тому же могут быть ещё не массивами, а скажем связными списками или вообще деревьями. Это всё абсолютно не соответствует реляционной модели, но при этом очень удобно в использование в приложение.
И приводит к дичайшим тормозам, как только объём этой кунсткамеры перестаёт помещаться в RAM.
_>А вот при реализации слоя абстракции БД, мы можем спокойно работать в приложение с такими сущностями и спокойно отправлять их в хранилище. А там уже слой абстракции разберётся как сохранить подобные объекты (например задействовать несколько таблиц со связями) в реляционной БД. А если очень захочется и в не реляционной.
Да-да, именно этот способ обеспечения работы с большими графами объектов и при необходимости сохранять данные между перезапусками приложения и является наихудшим выбором с точки зрения производительности и надёжности.