Здравствуйте, Sinclair, Вы писали:
_>>Что значит мощнее? Приложение ограниченное реляционной моделью на уровне внутренних классов будет весьма убого выглядеть по сравнению с нормальным (где реляционная модель всплывает только при работе с хранилищем). Ну ты же сам хорошо понимаешь, что совершенно нормально иметь в приложение коллекции объектов, поля которых тоже являются коллекциями других объектов. Причём коллекции эти к тому же могут быть ещё не массивами, а скажем связными списками или вообще деревьями. Это всё абсолютно не соответствует реляционной модели, но при этом очень удобно в использование в приложение. S>И приводит к дичайшим тормозам, как только объём этой кунсткамеры перестаёт помещаться в RAM.
Хыхы, а ты знаком с такой областью деятельности как физическое моделирование, обработка экспериментальных данных и т.п.? ) В курсе какие там объёмы данных гуляют? И какие там жёсткие требования на быстродействие? А слышал о применение там sql? )))
S>Да-да, именно этот способ обеспечения работы с большими графами объектов и при необходимости сохранять данные между перезапусками приложения и является наихудшим выбором с точки зрения производительности и надёжности.
При работе с большими графами следует вообще отказаться от реляционных БД.
Здравствуйте, gandjustas, Вы писали:
G>Хранимки дают типобезпосность. Если ты не в курсе, то ad-hoc запросы с параметрами в MS SQL реализуются через хранимку. А в некоторых базах транзакционность возможна только в хранимках.
G>Кроме того есть такая штука как тригеры, которая по сути поверх хранимок работает.
Не суть, как оно реализовано внутри. Если мы решили использовать чистый Linq, то БД может не выставлять наружи никакого API кроме linq-провайдера. В коде приложения мы пишем только linq-запросы, а провайдер может связываться с БД через какой угодно API.
K>>А то что единый фреймворк .NET заменяется на набор отдельно подключаемых сборок ты как воспринмаешь? Если СУБД будет также свободно собираться из подключаемых сборок — в чём проблема? G>Не понял вопроса.
Я имею в виду .NET Core: вместо единого фреймворка теперь нужно будет использовать отдельные nuget-пакеты. То есть мы используем только то, что нужно. Фактически, возможности одного конкретного приложения уменьшены. Урезает это какие-либо гарантии?
Сейчас существуют и всегда существовали разные версии SQL Server (как и других СУБД), от Express до Enterprise. Если не нужны фичи последней, то зачем за неё платить? Выбираем более дешёвую, с меньшими возможностями. Если добавить API, специально разработанный для эффективного взаимодействия с linq-провайдером, при этом выкинув ставшие ненужными другие возможности, то и на такую версию найдутся потребители.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, у Трака не так же. У него вообще очень тонкий слой изоляции от БД. Несколько БД поддерживает только базовый уровень, который у трака совсем простой. А запросы посложнее, которые нужны когда ты тикеты как то хитро выбрать хочешь, вот прям в SQL целевой БД и пишутся.
Какое написание запросов, ты вообще о чём? Мне не надо писать никакого sql кода для использования Trac'a. Я просто ставлю его на машину, подключаю к своей БД (4 варианта) и использую. Всё. И между прочим, я сам это делал, как раз из-за того, что там мой любимый питончик, но потом в итоге мы предпочли Redmine (кстати, умеет 5 разных СУБД), как более удобный и качественный продукт, хотя и на нелюбимом мною Ruby. И с ним опять же не надо было писать никакого "SQL в целевой БД", а можно просто подключить свою (по сути любую) СУБД.
Да, а правильный слой абстракции и должен быть тонким. И между прочим во всех этих phpBB он по сути точно такой же. С поправкой на унылый язык. )))
НС>И это ровно то, о чем тебе пытаются вдолбить несколько человек — пытаешься поддержать несколько БД без переписывания всех запросов — получаешь непотребный перфоманс.
А где это я говорил про "без переписывания"? Как раз я везде говорил, что наличие тонкого слоя абстракции позволяет нам легко сделать оптимальную реализацию под каждую СУБД.
Здравствуйте, koodeer, Вы писали:
K>Сейчас существуют и всегда существовали разные версии SQL Server (как и других СУБД), от Express до Enterprise. Если не нужны фичи последней, то зачем за неё платить? Выбираем более дешёвую, с меньшими возможностями.
Вот поэтому авторы существующих коммерческих СУБД точно на такое никогда не пойдут. )))
Да и бесплатным тоже будет сложновато разбить свой продукт на модули. Максимум можно надеяться на отключение ненужной функциональности в конфигах.
Или же ждать появления новых СУБД, построенных с нуля.
Здравствуйте, alex_public, Вы писали:
_>Какое написание запросов, ты вообще о чём?
О траке. Если ты захочешь Custom Query чуть менее примитивный, или в плагине к БД сходить — SQL в руки и вперед.
НС>>И это ровно то, о чем тебе пытаются вдолбить несколько человек — пытаешься поддержать несколько БД без переписывания всех запросов — получаешь непотребный перфоманс.
_>А где это я говорил про "без переписывания"? Как раз я везде говорил, что наличие тонкого слоя абстракции позволяет нам легко сделать оптимальную реализацию под каждую СУБД.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Какое написание запросов, ты вообще о чём? НС>О траке. Если ты захочешь Custom Query чуть менее примитивный, или в плагине к БД сходить — SQL в руки и вперед.
Ещё раз: я не занимаюсь написанием плагинов к движкам, я просто пользуюсь этими движками. Подключая их к практически произвольной СУБД (кстати, а для тестов на локальной машине очень удобно использовать sqlite) и всё работает, "из коробки". Как раз благодаря наличию в них подобного слоя абстракции БД. Хорошо и авторам движка и их пользователям. И такая ситуация наблюдается в большинстве случаев.
Так что ты всё же определись: "коробочные" движки — это с твоей точки зрения плохо (тогда почему советовал людям ставить Trac?) или хорошо (тогда куда девать твоё гениальное высказывание: "Любой приличный сайт использует свой софт. На "движках", в которых свои запросы не пишут только рекламный примитив собрать можно."?)
_>>А где это я говорил про "без переписывания"? Как раз я везде говорил, что наличие тонкого слоя абстракции позволяет нам легко сделать оптимальную реализацию под каждую СУБД. НС>Ценой значительного увеличения объема кода.
Ну так оно же не впустую, а увеличивает доступную долю рынка. )
Здравствуйте, alex_public, Вы писали:
_>Ещё раз: я не занимаюсь написанием плагинов к движкам
Мне совершенно пофигу чем ты занимаешься. Здесь обсуждались и обсуждаются технологии программирования. С админскими вопросами обращаяся к кому нибудь другому.
НС>>Ценой значительного увеличения объема кода. _>Ну так оно же не впустую, а увеличивает доступную долю рынка. )
Не всегда. Да и с траком сильно сомневаюсь в заметном проценте внешнего бекенда. Все известные мне инсталляции использовали встроенный sqlite.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Мне совершенно пофигу чем ты занимаешься. Здесь обсуждались и обсуждаются технологии программирования. С админскими вопросами обращаяся к кому нибудь другому.
Ну так авторов Trac'a устраивает их слой абстракции, не так ли? ) Или же у них там имеется раскиданные по коду запросы под конкретные СУБД? )))
Здравствуйте, alex_public, Вы писали:
_>Какое написание запросов, ты вообще о чём? Мне не надо писать никакого sql кода для использования Trac'a. Я просто ставлю его на машину, подключаю к своей БД (4 варианта) и использую. Всё. И между прочим, я сам это делал, как раз из-за того, что там мой любимый питончик, но потом в итоге мы предпочли Redmine (кстати, умеет 5 разных СУБД), как более удобный и качественный продукт, хотя и на нелюбимом мною Ruby.
Местный Janus поддерживает 13 СУБД, если не считать принципиальные различия в DB2 LUW vs z/OS и SqlServer 2000 vs 2014. Правда я не уверен, что кому-нибудь понадобиться хостить базу сообщений RSDN на мейнфрейме в DB2 z/OS или SAP HANA. Но, например, в Azure может оказаться хоститься вполне прикольно.
НС>>И это ровно то, о чем тебе пытаются вдолбить несколько человек — пытаешься поддержать несколько БД без переписывания всех запросов — получаешь непотребный перфоманс. _>А где это я говорил про "без переписывания"? Как раз я везде говорил, что наличие тонкого слоя абстракции позволяет нам легко сделать оптимальную реализацию под каждую СУБД.
linq2db позволяет обойтись без всякого тонкого слоя абстракции, а лишь настройкой модели данных.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Местный Janus поддерживает 13 СУБД, если не считать принципиальные различия в DB2 LUW vs z/OS и SqlServer 2000 vs 2014. Правда я не уверен, что кому-нибудь понадобиться хостить базу сообщений RSDN на мейнфрейме в DB2 z/OS или SAP HANA. Но, например, в Azure может оказаться хоститься вполне прикольно.
Не в курсе кто такой Janus. ))) Но результат отличный!
IT>linq2db позволяет обойтись без всякого тонкого слоя абстракции, а лишь настройкой модели данных.
Тут возможно возникла некая путаница между архитектурными и прикладными вопросами. Они безусловно связаны, но не однозначно. Попробую пояснить:
1. Слой абстракции БД конечно же является не единственным возможным способом обеспечить переносимость (между разными СУБД) кода. Большинство ORM это умеют. Но лично я сомневаюсь в эффективности (быстродействие) такого подхода, т.к. довольно сложно сделать универсальный код эффективным с любой СУБД. В то время как в частных случаях это очевидно делается без проблем.
2. Слой абстракции БД не имеет своей единственной целью переносимость — он вполне себе встречается в решениях заточенных под одну СУБД, т.к. является архитектурным артефактом.
Здравствуйте, alex_public, Вы писали:
IT>>Местный Janus поддерживает 13 СУБД, если не считать принципиальные различия в DB2 LUW vs z/OS и SqlServer 2000 vs 2014. Правда я не уверен, что кому-нибудь понадобиться хостить базу сообщений RSDN на мейнфрейме в DB2 z/OS или SAP HANA. Но, например, в Azure может оказаться хоститься вполне прикольно.
_>Не в курсе кто такой Janus. ))) Но результат отличный!
Читалка местных форумов. Там, конечно, не все базы используются, но насколько мне известно, специфичного для баз данных кода практически нет. Кажется, только при создании БД, чем и ограничено число баз, поставляемых по умолчанию. Но, т.к. вопрос базы данных для linq2db решается на уровне app.config, то подключить любую из поддерживаемых не должно быть проблемой.
_>1. Слой абстракции БД конечно же является не единственным возможным способом обеспечить переносимость (между разными СУБД) кода. Большинство ORM это умеют. Но лично я сомневаюсь в эффективности (быстродействие) такого подхода, т.к. довольно сложно сделать универсальный код эффективным с любой СУБД. В то время как в частных случаях это очевидно делается без проблем.
Вопрос генерации эффективного SQL — это дело техники. Никаких принципиальных ограничений на это нет. Например, пейдджинг практически для всех БД реализован по разному, именно так, как это более эффективно для конкретной БД. Тоже самое с InsertOrUpdate. Есть другая проблема. Некоторые БД не подддерживают некоторые возможности, как, например, Sybase не поддерживат TOP в подзапросах. В результате один и тот же linq запрос где-то будет работать, а где-то не очень. В этом случае придётся разруливать всё вручную.
_>2. Слой абстракции БД не имеет своей единственной целью переносимость — он вполне себе встречается в решениях заточенных под одну СУБД, т.к. является архитектурным артефактом.
Слой абстракции БД может нести в себе две функции: абстракцию от БД и абстракцию вообще. Если всё сделано ради первого, а не ради второго, то с использованием linq слой абстракции БД не нужен. При этом при его устранении происходит существенное упрощение приложения:
— исчезают pass-through слои и методы,
— исчезают лишние DTO объекты, обеспечивающие ad-hoc запросы
— конкретная логика концентрируется в одном месте, что даёт существенную прибавку к восприятию кода и определённую гибкость при его модификации,
— исчезает соблазн повторного использования бизнес-логики, чаще всего приводящего к монструозным методам с десятками параметров и запутанной логикой их использования внутри.
Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alex_public, Вы писали:
_>Или же у них там имеется раскиданные по коду запросы под конкретные СУБД? )))
Там имеются раскиданные по коду запросы, которые, в силу похожести диалектов SQL, таки более менее одинаково выполняются на sqlite и postgree. Абстракции в траке накинуты только поверх CRUD.
Здравствуйте, IT, Вы писали:
IT>Вопрос генерации эффективного SQL — это дело техники. Никаких принципиальных ограничений на это нет. Например, пейдджинг практически для всех БД реализован по разному, именно так, как это более эффективно для конкретной БД. Тоже самое с InsertOrUpdate. Есть другая проблема. Некоторые БД не подддерживают некоторые возможности, как, например, Sybase не поддерживат TOP в подзапросах. В результате один и тот же linq запрос где-то будет работать, а где-то не очень. В этом случае придётся разруливать всё вручную.
Это зависит от уровня абстракции ORM. Если мы имеем тяжёлую ORM (в которой весь код имеет вид db.persist(obj); ), то т.к. она полностью скрывает весь вид запросов внутри себя, то в принципе можно всю зависимость от вида СУБД там и оставить (с другой стороны такие ORM не особо эффективны сами по себе, вне зависимости от переносимости). Если же мы имеет дело с лёгкой ORM (где активно используется sql синтаксис), то уже можно очень легко наткнуться в прикладном коде на особенности конкретных СУБД.
IT>Слой абстракции БД может нести в себе две функции: абстракцию от БД и абстракцию вообще. Если всё сделано ради первого, а не ради второго, то с использованием linq слой абстракции БД не нужен. При этом при его устранении происходит существенное упрощение приложения:
Я согласен. Linq, как пример лёгкой ORM вполне себе осуществляет абстракцию от СУБД. Более того, у него есть свои модные плюсы. Но есть и минусы:
1. Т.к. это лёгкая ORM, то всё же можно в прикладном коде наткнуться на разную обработку запросов разными СУБД.
2. У linq не всё в порядке с эффективностью. Уже в смысле накладных расходов, а не особенностей sql. Что собственно и обсуждалось в данной теме.
IT>Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.
Конечно. Но в этой теме опять же показывали, что возможна статическая типизация sql запросов без накладных расходов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Там имеются раскиданные по коду запросы, которые, в силу похожести диалектов SQL, таки более менее одинаково выполняются на sqlite и postgree. Абстракции в траке накинуты только поверх CRUD.
Ужас какой. ))) Не зря мы от него отказались (хотя в код не заглядывали). Нет ничего хуже половинчатых решений. Кстати, а mysql тогда как там живёт? )
Здравствуйте, alex_public, Вы писали:
_>Хыхы, а ты знаком с такой областью деятельности как физическое моделирование, обработка экспериментальных данных и т.п.? ) В курсе какие там объёмы данных гуляют? И какие там жёсткие требования на быстродействие?
Знаком. _>А слышал о применение там sql? )))
Нет. Потому что с точки зрения SQL, все эти "обработки экспериментальных данных" малоинтересны. Ну надо сделать свёртку двух рядов, по терабайту каждый. И что? Это примитивный алгоритм, который ещё и хорошо параллелится, а при сбое его всегда можно перезапустить заново.
S>>Да-да, именно этот способ обеспечения работы с большими графами объектов и при необходимости сохранять данные между перезапусками приложения и является наихудшим выбором с точки зрения производительности и надёжности.
_>При работе с большими графами следует вообще отказаться от реляционных БД.
Если вам нужны гарантии восстановления после сбоев и ACID, то альтернативы RDBMS у вас нет. И работают они на отлично — особенно если отказаться от наркомании типа "давайте засосём в память все остатки по складам, залочим их, побегаем по ним курсорами, а потом скинем обратно пачку апдейтов", которую навяливают традиционные ORM конструкты.
Вы, для смеху, поинтересуйтесь результатами тестов TPC-C. Там ни один хибернейт и в топ-100 не попадёт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Нет там ни одного реального способа. Есть только набор полухаков с трудом эмулирующих нормальную работу. Причём традиционно их там два типа: невменяемо тормозные (через рекурсивные запросы к БД) или просто тормозные с нарушением типизации (через пути в виде строк и т.п.).
Ради интереса посмотрите Closure Table — там небольшой геморрой со вставкой, но все поддеревья можно выбирать одним запросом (без рекурсии).
Если нам не помогут, то мы тоже никого не пощадим.
