M>>Для «движков» — да. Только буквально в первый же день использования такого движка приложение, которое на нем строится оказывается строго заточено под один определенный движок. По вполне понятным причинам.
_>Ну если мы говорим про конкретную инсталляцию, то естественно, что после установки она работает только с одной базой — какой смысл прыгать то? ) Главное что в момент инсталляция можно выбрать любую СУБД.
/o\
Не может. Потому что несмотря на заточенность «движка», приложение почти сразу будет использовать специфические для выбранной БД запросы.
Это реально было PHP поставлялся с mysql_escape_string. Потом оказалось, что он работает неправильно. Поэтому вставили mysql_real_escape_string. И он работает так себе, поэтому они потом наконец осилили параметризованные запросы
Здравствуйте, alex_public, Вы писали:
_>Мда?) Ну и как в этой единственной модели получают "производительное" хранение например деревьев? )
Стандартными способами. А что, есть способ ускорить реляционное хранилище, отойдя от реляционной модели при работе с ним?
_>Хороший слой абстракции БД будет работать в терминах приложения, а не sql таблиц.
А LINQ и работает в терминах приложения, внезапно. Просто модель данных в приложении — реляционная.
_> Я тут уже приводил пример. Если у нас есть такой уровень, то в нём будет грубо говоря функция вида dbAddUser(...). _> А без такого уровня будет несколько строк с INSERT в разные таблицы, которые надо будет копипастить по приложению.
Для создания функции совершенно не обязательно создавать отдельный уровень абстракции.
НС>>Я считаю что в большинстве случаев абстракция над абстракцией IQueryable — не просто никчемная, а крайне вредная вещь. _>Чем это оно может быть вредным в языке с нормальной оптимизацией? )
Никакая оптимизация не спасет тебя от проблем с лишней абстракцией, ломающей исходную модель данных.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Там собственно и "говнокодить" намного проще, т.к. вообще нет конкуренции (между продукцией). G>>А это тут при чем? И как связано с базами? Говнокодинг совершенно независим от того сколько баз поддерживается.
_>Говнокодинг тут привязан не к БД, а внутрикорпоративному софту. Т.к. там достаточно добиться того, чтобы приложение кое-как шевелилось (соответствовало ТЗ), и можно скидывать с рук. А в мире нормального софта этого мягко говоря недостаточно, т.к. полно конкурентов и "просто работает" у всех. Тут надо ещё добавлять фичи (в том числе количество поддерживаемых СУБД) и поднимать качество (избавляться от говнокода).
говнокод совершенно не зависит от конкуренции, он зависит от отношения менеджеров к говнокоду. Конкуренция в корпоративном софте огромная, большая часть программистов занимаются корпоративной разработкой, есличто.
G>>А при чем тут движки, если мы говорим о разработке приложений? Пользователю вообще пофиг что там в бекэнде вордпресса. Не пофиг именно программистам. Если им надо обеспечить хостинг на 100500 платформах и производительность некритична, то имеет смысл заморачиваться на несколько баз, но в большинстве случаев ровно наоборот. Платформа известна заранее, а приложение надо сделать быстрым и надежным.
_>В вебе сейчас во многих случаях "приложение" собирается не программистом, а админом из набора готовых движков, которые надо только правильно установить и сконфигурировать.
И все эти случаи нас не интересуют.
G>>Ты о каких "потерях" пишешь? Среднее время обработки запроса процессором по отношению к общему времени — не боле 5%, какая разница что там C#\linq или PHP, важно какие запросы генерируются, а они как раз сильно лучше в случае linq.
_>Ну вообще то это всё не совсем так, но пускай даже прямо так и есть. Тогда тем более непонятно почему ты против добавления слоя абстракции БД (у нас же именно об этом шёл разговор!) — ведь судя по твоим словам процессор то всё равно простаивает всё время, так что можно без проблем добавить ещё хоть десяток слоёв. )))
Потому что абстракцию поверх linq ты не напишешь, а все что напишешь будет приводить к более тормозным запросам. Похоже ты не в теме корпоративной разработки вообще.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>То есть пришли к тому же выводу — фактически никто не поддерживает "хорошее" кеширование. Да и его "хорошесть" крайне сомнительна.
_>Ничего, обычное тупое тоже достаточно эффективно и есть практические во всех БД. )
А у тебя есть замеры? Только не точечные, а по всему приложению? Причем так чтобы база не влезала в ОП.
G>>Я делал такое, производительность возрастала в разы. Без всяких извращений на C++. Распределенные кеши имеют такой простой API, что синхронизировать их между серверами почти ничего не стоит.
_>Угу, возрастала в разы относительно случая без кэша. А если бы применил вместо этого кэш в БД, то выросло бы не в разы, а в десятки раз.
Откуда такая уверенность? Ты понимаешь как БД работает вообще? Я вот понимаю и не вижу откуда возьмутся десятки раз. Ты очень далек от бд и архитектуры, на основании чего утверждаешь?
G>>Ты просто не понял код или сделал вид, что не понял. Я тебе пытался объяснить, но ты продолжал делать вид. Я сомневаюсь, что ты настолько не в теме как работает linq, значит просто пытался сузить задачу до удобной тебе. Увы, показанное тобой "решение" крайне далеко от того, что реально делается с помощью linq.
_>Я так понял, что примера кода (который надо повторить на sqlcpp11 и потом сравнить производительность) не будет? )
Он такой же остался, ты его так и не повторил. Существенное условие у тебя не выполняется — возможность передачи запросов в другие сборки (dll).
G>>>>На клиенте гораздо удобнее когда схема датасета не меняется. _>>>Дааа? ))) А как же ты тогда столько тут распинался в полезности проекций? ) G>>А с чего ты решил, что проекция стала бесполезна? Ты не знаешь как работает SQL или у тебя другие причины?
_>Я не очень понял как коррелируют твои слова о пользе проекции (причём динамической) с твоим же словами о том, что лучше, когда датасет не меняется.
Проекция в принципе нужна для увеличения быстродействия запросов. Приложению удобно иметь фиксированную схему датасета, чтобы можно было типизацию прикрутить. При этом построение запроса по кускам от проекции зависеть не должно. Что тебе не понятно?
G>>Для начала надо сгенерировать запрос, который эффективно использует индексы и не снижает поддерживаемость приложения. Как это сделать без linq мы пока не увидели.
_>Это учат каждого студента, при изучение собственно sql.
То есть ты предлагаешь выписывать sql руками?
Здравствуйте, IT, Вы писали:
_>>Ну да, это уже была речь не про обсуждаемый здесь linq к БД, а про просто linq, который ещё более печален. IT>Ты его сам видел хотя бы один раз вблизи?
Конечно видел и его и аналогичные или лучшие инструменты из других языков. Но даже если я сейчас напишу тебе подробный анализ базовых принципов, то боюсь ты всё равно не воспримешь его всерьёз от меня, т.к. я не являюсь признанным специалистом по C#. А для тебя весь важно именно это, а не общетеоретические основы. Но ведь можно легко найти множество аргументов и для таких как ты. Например взглянуть на наверняка известный тебе инструмент ReSharper — как ты считаешь, его создателей можно считать специалистами по C# или нет? ) Ну и если можно, то как тогда объяснить их отказ от использования linq? )
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Пара миллисекунд практически на ровном месте. Да это же 1/50 секунды современного железа! НС>1/500
Точно, ошибся. Спасибо что исправил.
Тем не менее, это всё равно очень много. Например у меня такой ping на домашнем wifi, без всяких доп настроек — так тут много чего происходит, много слоёв. А в случае LINQ — это считай на ровном месте, и причём это не просто задержка, это ещё и загрузка процессора.
Здравствуйте, Mamut, Вы писали:
M>Не может. Потому что несмотря на заточенность «движка», приложение почти сразу будет использовать специфические для выбранной БД запросы.
И это вызовет привязку к конкретной БД как раз только в случае отсутствия слоя абстракции БД. А в нормальных местах работа идёт именно через него + имеем набор реализаций этого слоя под каждую конкретную БД, где и используются те самые специфические запросы.
Здравствуйте, gandjustas, Вы писали:
G>>>При чем это говно скорее всего сделает приложение медленнее. EP>>Так ты определись — либо у LINQ действительно есть непроизводственные расходы, и аналог без этих расходов всегда будет не медленнее, либо же это полезные расходы — но приносят пользу только для части случаев. G>Аналог без этих расходов повышает сложность реализации
Не сильно. Зато учитывая то, насколько этот инструмент широко используется — постараться всё-таки стоило/стоит
G>и делает результат хуже в подавляющем большинстве случаев.
С чего бы это?
Я говорю о том, что с LINQ можно срезать лишний runtime жир, не потеряв при этом способность генерировать тот же результат. Согласен?
EP>>>>А при чёт тут вообще индексы? Речь о том что только на построении запроса теряется несколько миллисекунд. EP>>>>Или ты хочешь сказать что те кто используют LINQ делают кривые индексы, и соответственно непроизводственный оверхед LINQ'а рояли не играет? G>>>Нет, я хочу сказать, что linq позволяет построить более эффективные запросы, что гораздо важнее, чем пара мсек. EP>>Более эффективные чем что? G>Чем запросы сделанные без linq.
Что мешает построить эффективный запрос без LINQ? Например каким-нибудь другим декларативным способом, или тем же "обезжиренным" LINQ?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Мда?) Ну и как в этой единственной модели получают "производительное" хранение например деревьев? ) НС>Стандартными способами. А что, есть способ ускорить реляционное хранилище, отойдя от реляционной модели при работе с ним?
Ну так значит "внезапно" реляционная модель оказывается не единственной полезной? )
_>>Хороший слой абстракции БД будет работать в терминах приложения, а не sql таблиц. НС>А LINQ и работает в терминах приложения, внезапно. Просто модель данных в приложении — реляционная.
Да ничего подобного. Модель приложения практически всегда более строгая, чем просто реляционная. И при необходимости эти ограничения легко (во всяком случае в языках со статической типизацией) вводятся в код. Например можно элементарно запретить складывать рубли с килограммами и т.п. Чистая реляционная модель ничего подобного не предусматривает.
_>> Я тут уже приводил пример. Если у нас есть такой уровень, то в нём будет грубо говоря функция вида dbAddUser(...). _>> А без такого уровня будет несколько строк с INSERT в разные таблицы, которые надо будет копипастить по приложению. НС>Для создания функции совершенно не обязательно создавать отдельный уровень абстракции.
Если ты считаешь вышеприведённый пример не введением дополнительного слоя абстракции (под которым кстати может быть и работа с не sql базой), то что это тогда? )
НС>Никакая оптимизация не спасет тебя от проблем с лишней абстракцией, ломающей исходную модель данных.
Что ты называешь тут моделью данных? Из БД приходит грубо говоря просто массив (в бинарном виде). В нормальном языке мы можем интерпретировать его как угодно, без всяких потерь с производительностью.
Здравствуйте, gandjustas, Вы писали:
G>говнокод совершенно не зависит от конкуренции, он зависит от отношения менеджеров к говнокоду. Конкуренция в корпоративном софте огромная, большая часть программистов занимаются корпоративной разработкой, есличто.
Ты не путай конкуренцию между программистами и конкуренцию между продуктами. Это совершенно разные вещи, которые иногда могут приводить даже к противоположным последствиям.
G>Потому что абстракцию поверх linq ты не напишешь, а все что напишешь будет приводить к более тормозным запросам. Похоже ты не в теме корпоративной разработки вообще.
Под конкретное приложение очень даже легко напишу. Только не поверх linq, а вместо — зачем затормаживать свой код изначально? ) И эта абстракция будет ещё и намного более безопасной, т.к. будет включать в себя ограничения недоступные sql (например не позволит складывать килограммы и рубли и т.п.).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
G>>>>При чем это говно скорее всего сделает приложение медленнее. EP>>>Так ты определись — либо у LINQ действительно есть непроизводственные расходы, и аналог без этих расходов всегда будет не медленнее, либо же это полезные расходы — но приносят пользу только для части случаев. G>>Аналог без этих расходов повышает сложность реализации EP>Не сильно. Зато учитывая то, насколько этот инструмент широко используется — постараться всё-таки стоило/стоит
Когда проектировали Expression Tree об этом не знали. Понимание как надо делать родилось более чем через 5 лет после того, как сделали.
G>>и делает результат хуже в подавляющем большинстве случаев. EP>С чего бы это? EP>Я говорю о том, что с LINQ можно срезать лишний runtime жир, не потеряв при этом способность генерировать тот же результат. Согласен?
В теории, но на практике пока никому не удалось. Теоретические изыскания неинтересны.
EP>Что мешает построить эффективный запрос без LINQ? Например каким-нибудь другим декларативным способом, или тем же "обезжиренным" LINQ?
Построить — ничего не мешает, а вот поддерживать — ад. Опять-так в теории все можно, а на практике есть linq и близких аналогов нет вообще.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>говнокод совершенно не зависит от конкуренции, он зависит от отношения менеджеров к говнокоду. Конкуренция в корпоративном софте огромная, большая часть программистов занимаются корпоративной разработкой, есличто.
_>Ты не путай конкуренцию между программистами и конкуренцию между продуктами. Это совершенно разные вещи, которые иногда могут приводить даже к противоположным последствиям.
А с чего ты взял что я путаю? Заказчик (как конечный пользователь, так и корп. заказчик) покупает услугу, хотя маркетологи называют её продуктом. Суть услуги в повышении прибыли (снижении издержек), медленное и глючное приложение издержки повышает. Причем конечного пользователя еще можно развести "красивостями" и "стилем", то для корпоративного заказчика такая хрень не катит. Если ты сделал даже очень красивое говно, то с тобой перестанут сотрудничать.
И если для дескопного софта есть 2-3 альтернативы, которые конкурируют между собой, то в корпоративном секторе сотни компаний готовы оказывать услуги.
G>>Потому что абстракцию поверх linq ты не напишешь, а все что напишешь будет приводить к более тормозным запросам. Похоже ты не в теме корпоративной разработки вообще.
_>Под конкретное приложение очень даже легко напишу. Только не поверх linq, а вместо — зачем затормаживать свой код изначально? ) И эта абстракция будет ещё и намного более безопасной, т.к. будет включать в себя ограничения недоступные sql (например не позволит складывать килограммы и рубли и т.п.).
Ты все еще веришь в то, что сможешь генерировать запросы лучше, чем умеет linq? Ты похоже никогда этим не занимался.
Здравствуйте, gandjustas, Вы писали:
G>А у тебя есть замеры? Только не точечные, а по всему приложению? Причем так чтобы база не влезала в ОП.
Угу, есть. И не точечные. Правда не какого-то большого приложения, а специально написанного мелкого тестового.
Да, и кстати чем больше база, тем собственно больше будет бонус от подключения кэша (он то по любому в оперативной памяти сидит и при этом занимает не особо много места).
_>>Угу, возрастала в разы относительно случая без кэша. А если бы применил вместо этого кэш в БД, то выросло бы не в разы, а в десятки раз. G>Откуда такая уверенность? Ты понимаешь как БД работает вообще? Я вот понимаю и не вижу откуда возьмутся десятки раз. Ты очень далек от бд и архитектуры, на основании чего утверждаешь?
Ну собственно бонус от введения кэша очевидно зависит от среднего времени выполнения запросов без кэша, т.к. время обращения к базе в случае попадания в кэш можно условно говоря считать константой (причём обычно очень малой — меньше 1 мс). Т.е. грубо говоря если у тебя запросы и так быстрые, то включения кэша в БД естественно не принесёт особых бонусов. А вот если у тебя запросы могут под секунду выполняться, то в случае включения кэша можно получить ускорение и в сотни раз.
Естественно это всё касается случаев, когда кэширование запросов вообще применимо — можно же подобрать ситуацию, когда вообще кэш не будет работать. Но это скорее исключения из правил. Обычно часть запросов отлично кэшируется, что даёт в итоговой сумме неплохое увеличение производительности.
_>>Я так понял, что примера кода (который надо повторить на sqlcpp11 и потом сравнить производительность) не будет? ) G>Он такой же остался, ты его так и не повторил. Существенное условие у тебя не выполняется — возможность передачи запросов в другие сборки (dll).
Всё с тобой понятно.
_>>Я не очень понял как коррелируют твои слова о пользе проекции (причём динамической) с твоим же словами о том, что лучше, когда датасет не меняется. G>Проекция в принципе нужна для увеличения быстродействия запросов. Приложению удобно иметь фиксированную схему датасета, чтобы можно было типизацию прикрутить. При этом построение запроса по кускам от проекции зависеть не должно. Что тебе не понятно?
Да всё понятно теперь. ))) Просто только приперев тебя к стенке удалось выяснить, что реально тебе нужны совсем не динамические запросы. А как раз классические статические, но конструируемые по частям.
G>То есть ты предлагаешь выписывать sql руками?
Ну это смотря какие инструменты есть в языке. В случае например C++ руками не требуется. Это если ты спрашиваешь именно про sql строки. Потому как если говорить о смысловом наполнение, то работа и с linq и sqlcpp11 является как раз той самой ручной работой с sql.
Здравствуйте, Слава, Вы писали:
_>>Конечно видел и его и аналогичные или лучшие инструменты из других языков. С>Из каких "других языков"? В каких широко распространенных языках есть цитирование кода?
Sequence в Swift'e, std.range в D, boost.range в C++ и т.п. Это только то, что навскидку вспомнилось. А если специально пройтись по всем языкам, то наверняка ещё множество наберётся. ) Мы же тут заговорили про аналог обычного linq, а не про БД.
Здравствуйте, gandjustas, Вы писали:
G>А с чего ты взял что я путаю? Заказчик (как конечный пользователь, так и корп. заказчик) покупает услугу, хотя маркетологи называют её продуктом. Суть услуги в повышении прибыли (снижении издержек), медленное и глючное приложение издержки повышает. Причем конечного пользователя еще можно развести "красивостями" и "стилем", то для корпоративного заказчика такая хрень не катит. Если ты сделал даже очень красивое говно, то с тобой перестанут сотрудничать. G>И если для дескопного софта есть 2-3 альтернативы, которые конкурируют между собой, то в корпоративном секторе сотни компаний готовы оказывать услуги.
Ты путаешься в терминологии. Внутрикорпоративный софт — это не тот, который просто используется внутри корпораций, а тот, который пишется в них (т.е. пишется в IT отделе не IT компании, а не покупается у специализированной IT компании). Т.е. тот же MSSQL очевидно не является внутрикорпоративным софтом. А вот формочка для ввода данных сотрудниками в банке именно им и является.
G>Ты все еще веришь в то, что сможешь генерировать запросы лучше, чем умеет linq? Ты похоже никогда этим не занимался.
Что значит генерировать запросы лучше, чем linq? ) SQL строка отсылаемая в СУБД будет очевидно точной такой же, как и у linq варианта. Только при её генерации не будет таких диких накладных расходов, как у linq. Плюс если в приложение будет реализован нормальный слой абстракции БД, то мы можем получить ещё и более удобный и безопасный внутренний API.
Здравствуйте, alex_public, Вы писали:
_>>>Мда?) Ну и как в этой единственной модели получают "производительное" хранение например деревьев? ) НС>>Стандартными способами. А что, есть способ ускорить реляционное хранилище, отойдя от реляционной модели при работе с ним? _>Ну так значит "внезапно" реляционная модель оказывается не единственной полезной? )
Извивы твоей логики от меня ускользают.
_>>>Хороший слой абстракции БД будет работать в терминах приложения, а не sql таблиц. НС>>А LINQ и работает в терминах приложения, внезапно. Просто модель данных в приложении — реляционная. _>Да ничего подобного.
Ну да, расскажи мне что такое линк.
_> Модель приложения практически всегда более строгая, чем просто реляционная.
В каком смысле?
_> И при необходимости эти ограничения легко (во всяком случае в языках со статической типизацией) вводятся в код.
Бизнес ограничения вообще не должны быть в модели, это независимый слой. Который неплохо бы в современных реалиях сделать декларативным, иначе придется императивщину дублировать на клиенте. Но, в любом случае, валидации внутри модели точно не место — SRP панимаишь.
_> Например можно элементарно запретить складывать рубли с килограммами и т.п. Чистая реляционная модель ничего подобного не предусматривает.
Это нахрен никому не нужно. Я за весь свой экспириенс какого только говнокода не перевидал. Но вот чтобы рубли с килограммами складывали — с таким не встречался ни разу.
Ну и, наконец, линк задавать более специфичные типы для полей вовсе и не мешает. Те же енумы — каноничный пример. Проблемы начинаются, когда ты начинаешь ломать собственно реляции и заменять их объектными графами.
НС>>Для создания функции совершенно не обязательно создавать отдельный уровень абстракции. _>Если ты считаешь вышеприведённый пример не введением дополнительного слоя абстракции
А с чего бы мне считать обычную функцию аж слоем абстракции? Слой это когда ты полностью все закрываешь. А когда у тебя чтение пользователей все равно через IQueryable идет — никакой это не слой.
НС>>Никакая оптимизация не спасет тебя от проблем с лишней абстракцией, ломающей исходную модель данных. _>Что ты называешь тут моделью данных?
Не всегда. Есть еще group by.
_> В нормальном языке мы можем интерпретировать его как угодно, без всяких потерь с производительностью.
Проблема в том, как этот массив получать и что в нем в каком виде содержится. Все эти мегаслои абстракции провоцируют навигационный доступ, ленивую загрузку, отсутствие проекций, фильтрацию в памяти и т.п., на чем все абстрактные замки и дохнут.
Здравствуйте, gandjustas, Вы писали:
G>>>и делает результат хуже в подавляющем большинстве случаев. EP>>С чего бы это? EP>>Я говорю о том, что с LINQ можно срезать лишний runtime жир, не потеряв при этом способность генерировать тот же результат. Согласен? G>В теории но на практике пока никому не удалось.
Из других областей примеров масса — некий EDSL оптимизируется во время компиляции и переводится в конкретный код, без всякого runtime обхода дерева выражений. Причём для разных языков — C++, D, Nemerle.
Не вижу ничего такого в LINQ что может помешать подобной реализации.
G>Теоретические изыскания неинтересны.
Почему же? В начале топика ты отрицал что это вообще возможно, теперь вот знаешь что это не так
EP>>Что мешает построить эффективный запрос без LINQ? Например каким-нибудь другим декларативным способом, или тем же "обезжиренным" LINQ? G>Построить — ничего не мешает, а вот поддерживать — ад.
То есть ты утверждаешь что поддерживать код с любым другим декларативным доступом к данным это ад?
Здравствуйте, alex_public, Вы писали:
_> Только при её генерации не будет таких диких накладных расходов, как у linq.
Какая восхитительная подмена. Внезапно, микросекунды уже стали "дикими" расходами, при том, что выше по треду убедительно разъяснялись пропорции расходов.
